nit

Author: danielsparing

docs/search.json

@@ -322,7 +322,7 @@
     "href": "viz/maplibregljs.html#create-a-sample-table",
     "title": "Scalable visualization with DuckDB Spatial MVT",
     "section": "",
-    "text": "We keep DuckDB doing the MVT generation incl. the preprocessing of calculating the ST_TileEnvelope for the tiles needed for the current viewport, but of course we need Databricks SQL to actually spatial filter our Delta Table (DuckDB delta_scan currently does not read GEOMETRY data types.)\n\nAn alternative approach could be to wrap the used DuckDB functions into Spark UDF’s, if we wanted to move some compute from your browser to DBSQL.\n\nFor DBSQL we use the Python databricks-sql-connector, authenticating with a Personal Access Token – for serious work, you’d want to use OAuth instead.\nGraceful feature limit. What to do if a tile has too many features? A common solution would be to define a minimum zoom level, but this would make it very cumbersome to move around the map, so we define a MAX_FEATURES_PER_TILE instead. If this is reached, we gracefully fail and only show the tile boundaries – the user would only need to further zoom in to reveal all the features within that viewport. (Of course you can throttle this value as you wish to find a balance between loading time and number of features shown.)\nMVT expects SRID 3857, while our table is probably in another SRID, so we need to use some st_transform there and back.\nTile throttling. we also added JS code under // === Tile throttling logic === to take a 2 second pause starting any zoom and move interaction, in order to avoid overloading the warehouse with tile requests and therefore avoid tile queueing.\n\nNote that in the current implementation this means that during zooming and moving the map, the feature layer is temporarily not visible – this probably could be improved. For example, without tile throttling, the objects would remain visible during zoom/pan, but we would need to wait much longer for the results after a big move.\n\n\n\n\n\n\n\nClick on the image to play the video.\n\n\n\n\n\n\n\n\n\nNote\n\n\n\nWhat if you find this approach still too “slow”, from the end-user standpoint? And/or, you find it “cheating” that we use MAX_FEATURES_PER_TILE? Then you can use PMTiles. The difference is that with the MVT approach, you directly read the Delta Lake table, and the PMTile you would need to generate which means extra compute and time.",
+    "text": "We keep DuckDB doing the MVT generation incl. the preprocessing of calculating the ST_TileEnvelope for the tiles needed for the current viewport, but of course we need Databricks SQL to actually spatial filter our Delta Table (DuckDB delta_scan currently does not read GEOMETRY data types.)\n\nAn alternative approach could be to wrap the used DuckDB functions into Spark UDF’s, if we wanted to move some compute from your browser to DBSQL.\n\nFor DBSQL we use the Python databricks-sql-connector, authenticating with a Personal Access Token – for serious work, you’d want to use OAuth instead.\nGraceful feature limit. What to do if a tile has too many features? A common solution would be to define a minimum zoom level, but this would make it very cumbersome to move around the map, so we define a MAX_FEATURES_PER_TILE instead. If this is reached, we gracefully fail and only show the tile boundaries – the user would only need to further zoom in to reveal all the features within that viewport. (Of course you can throttle this value as you wish to find a balance between loading time and number of features shown.)\nMVT expects SRID 3857, while our table is probably in another SRID, so we need to use some st_transform there and back.\nTile throttling. we also added JS code under // === Tile throttling logic === to take a 2 second pause starting any zoom and move interaction, in order to avoid overloading the warehouse with tile requests and therefore avoid tile queueing.\n\nNote that in the current implementation this means that during zooming and moving the map, the feature layer is temporarily not visible – this probably could be improved. For example, without tile throttling, the objects would remain visible during zoom/pan, but we would need to wait much longer for the results after a big move.\n\n\n\n\n\n\n\nClick on the image to play the video.\n\n\n\n\n\n\n\n\n\nNote\n\n\n\nIf you still find this approach too “slow” from the end-user standpoint, and/or you find it “cheating” that we use MAX_FEATURES_PER_TILE, then you can use PMTiles instead. The difference is that with the MVT approach, you directly read the Delta Lake table, and the PMTile you would need to generate which means extra compute and time.",
     "crumbs": [
       "Visualization",
       "<span class='chapter-number'>10</span>  <span class='chapter-title'>Scalable visualization with DuckDB Spatial MVT</span>"
@@ -388,7 +388,7 @@
     "href": "viz/PMTiles.html",
     "title": "Visualize with PMTiles",
     "section": "",
-    "text": "PMTiles (a tileserver in the form of a single file, read with Range Requests) is a powerful way to visualize very large datasets, see https://pmtiles.io . The key tool to generate one is tippecanoe.\nSee the end-to-end example for a PMTiles generation and visualization example.\n\n\n\n\n\n\nNote\n\n\n\nNote that the maps built on PMTiles are slippy maps, pannable and zoomable, unlike the screenshot of it below.\n\n\n\n\n\nrailnetwork",
+    "text": "PMTiles (a tileserver in the form of a single file, read with Range Requests) is a powerful way to visualize very large datasets, see https://pmtiles.io . The key tool to generate one is tippecanoe.\nSee here on how to use tippecanoe to create a PMTiles file, and for a more advanced example incl visualization, see this end-to-end notebook.\n\n\n\n\n\n\nNote\n\n\n\nNote that the maps built on PMTiles are slippy maps, pannable and zoomable, unlike the screenshot of it below.\n\n\n\n\n\nrailnetwork",
     "crumbs": [
       "Visualization",
       "<span class='chapter-number'>13</span>  <span class='chapter-title'>Visualize with PMTiles</span>"

docs/viz/PMTiles.html

@@ -351,7 +351,7 @@ <h1 class="title"><span class="chapter-title">Visualize with PMTiles</span></h1>
 
 
 <p>PMTiles (a tileserver in the form of a single file, read with Range Requests) is a powerful way to visualize very large datasets, see https://pmtiles.io . The key tool to generate one is <a href="https://github.com/felt/tippecanoe">tippecanoe</a>.</p>
-<p>See the <a href="../end2end/train_to_slopes.html">end-to-end example</a> for a PMTiles generation and visualization example.</p>
+<p>See <a href="../other_formats/export.html#pmtiles">here</a> on how to use tippecanoe to create a PMTiles file, and for a more advanced example incl visualization, see this <a href="../end2end/train_to_slopes.html">end-to-end notebook</a>.</p>
 <div class="callout callout-style-default callout-note callout-titled">
 <div class="callout-header d-flex align-content-center">
 <div class="callout-icon-container">

docs/viz/maplibregljs.html

@@ -498,7 +498,7 @@ <h2 class="anchored" data-anchor-id="create-a-sample-table">Create a sample tabl
 </div>
 </div>
 <div class="callout-body-container callout-body">
-<p>What if you find this approach still too “slow”, from the end-user standpoint? And/or, you find it “cheating” that we use <code>MAX_FEATURES_PER_TILE</code>? Then you can use <a href="../viz/PMTiles.html">PMTiles</a>. The difference is that with the MVT approach, you directly read the Delta Lake table, and the PMTile you would need to generate which means extra compute and time.</p>
+<p>If you still find this approach too “slow” from the end-user standpoint, and/or you find it “cheating” that we use <code>MAX_FEATURES_PER_TILE</code>, then you can use <a href="../viz/PMTiles.html">PMTiles</a> instead. The difference is that with the MVT approach, you directly read the Delta Lake table, and the PMTile you would need to generate which means extra compute and time.</p>
 </div>
 </div>
 

viz/PMTiles.ipynb

@@ -9,7 +9,7 @@
     "\n",
     "PMTiles (a tileserver in the form of a single file, read with Range Requests) is a powerful way to visualize very large datasets, see https://pmtiles.io . The key tool to generate one is [tippecanoe](https://github.com/felt/tippecanoe).\n",
     "\n",
-    "See the [end-to-end example](../end2end/train_to_slopes.ipynb) for a PMTiles generation and visualization example.\n",
+    "See [here](../other_formats/export.ipynb#pmtiles) on how to use tippecanoe to create a PMTiles file, and for a more advanced example incl visualization, see this [end-to-end notebook](../end2end/train_to_slopes.ipynb).\n",
     "\n",
     ":::{.callout-note}\n",
     "\n",

viz/maplibregljs.ipynb

@@ -198,7 +198,7 @@
     "\n",
     "::: {.callout-note}\n",
     "\n",
-    "What if you find this approach still too \"slow\", from the end-user standpoint? And/or, you find it \"cheating\" that we use `MAX_FEATURES_PER_TILE`? Then you can use [PMTiles](./PMTiles.ipynb). The difference is that with the MVT approach, you directly read the Delta Lake table, and the PMTile you would need to generate which means extra compute and time.\n",
+    "If you still find this approach too \"slow\" from the end-user standpoint, and/or you find it \"cheating\" that we use `MAX_FEATURES_PER_TILE`, then you can use [PMTiles](./PMTiles.ipynb) instead. The difference is that with the MVT approach, you directly read the Delta Lake table, and the PMTile you would need to generate which means extra compute and time.\n",
     "\n",
     ":::"
    ]