-
-Initially I thought the 4th bang might be referring to the [Google Place ID of the image](/blog/place-id-google-street-view), however both images show "The Queen's Walk" as the place, [and a lookup](https://developers.google.com/maps/documentation/javascript/examples/places-placeid-finder) of the `place ID` for the "The Queen's Walk" returns `EixUaGUgUXVlZW4ncyBXYWxrLCBTb3V0aCBCYW5rLCBMb25kb24gU0UxLCBVSyIuKiwKFAoSCekLrB7HBHZIEQ5z1qt4guCgEhQKEgk_J5VMtgR2SBFYYta2uf8XCQ`.
-
-Digging deeper, lets take another Street View image taken by Google and it's decoded URL:
-
-
-
-`https://www.google.co.uk/maps/@45.8326327,6.8634657,2a,75y,68.65h,91.77t/data=!3m7!1e1!3m5!1sk92ptfUShdo9lKo5PYMGew!2e0!6s//geo1.ggpht.com/cbk?panoid=k92ptfUShdo9lKo5PYMGew&output=thumbnail&cb_client=maps_sv.tactile.gps&thumb=2&w=203&h=100&yaw=10.15913&pitch=0&thumbfov=100!7i13312!8i6656`
-
-_Decoded URL, hence will not load correctly._
-
-The 8 bangs for this URL:
-
-```
-data=
-!3m7
-!1e1
-!3m5
-!1sk92ptfUShdo9lKo5PYMGew
-!2e0
-!6s//geo1.ggpht.com/cbk?panoid=k92ptfUShdo9lKo5PYMGew&output=thumbnail&cb_client=maps_sv.tactile.gps&thumb=2&w=203&h=100&yaw=10.15913&pitch=0&thumbfov=100
-!7i13312
-!8i6656
-
-```
-
-Again, only the the 6th bang (`panoId` and `yaw`) and the 4th bang change (1st URL = `!1sjJXYsBpPPqWuvSR5RUaIEQ` / 2nd URL = `!1s7YsnZ32rM6gi8Ivi2k3viA` / 3rd URL = `!1sk92ptfUShdo9lKo5PYMGew`).
-
-I'm still non-the wiser.
-
-This time, let's take a look at user uploaded content -- one of our panoramas (versus Google content):
-
-
-
-`https://www.google.co.uk/maps/@51.2895639,-0.8214139,3a,75y,1.74h,90t/data=!3m8!1e1!3m6!1sAF1QipP8Umrvyj6jz7HQFCJ1IGxUFo4tSfZdciNHyBqX!2e10!3e11!6shttps://lh5.googleusercontent.com/p/AF1QipP8Umrvyj6jz7HQFCJ1IGxUFo4tSfZdciNHyBqX=w203-h100-k-no-pi0-ya23.025953-ro0-fo100!7i5760!8i2880`
-
-_Decoded URL, hence will not load correctly._
-
-The *9 bangs* for this URL:
-
-```
-data=
-!3m8
-!1e1
-!3m6
-!1sAF1QipP8Umrvyj6jz7HQFCJ1IGxUFo4tSfZdciNHyBqX
-!2e10
-!3e11
-!6shttps://lh5.googleusercontent.com/p/AF1QipP8Umrvyj6jz7HQFCJ1IGxUFo4tSfZdciNHyBqX=w203-h100-k-no-pi0-ya23.025953-ro0-fo100
-!7i5760
-!8i2880
-```
-
-It seems user content is handled differently. Firstly, the URL is made up of 9 bangs.
-
-This time the 1st (`!3m8`), 3rd (`!3m6`), 4th (`!1sAF1QipP8Umrvyj6jz7HQFCJ1IGxUFo4tSfZdciNHyBqX`), 6th NEW (`!3e11`), 7th (pano info), 8th (`!7i5760`), and 9th (`!8i2880`) bangs are all different to the previous image.
-
-The pano info (7th bang, equivalent to the 6th bang for Google uploaded images) is also considerably different:
-
-`!6shttps://lh5.googleusercontent.com/p/AF1QipP8Umrvyj6jz7HQFCJ1IGxUFo4tSfZdciNHyBqX=w203-h100-k-no-pi0-ya23.025953-ro0-fo100`
-
-This time the host is different (`googleusercontent.com` vs `ggpht.com`). The `panoid` is defined after the `/p/` (in this case `AF1QipP8Umrvyj6jz7HQFCJ1IGxUFo4tSfZdciNHyBqX` vs. `panoid=`), and the `output=thumbnail` argument is replaced with what looks to be a reference to a thumbnail but in a different structure containing references to (_I think_) width (`w203`), height (`h100`), pitch (`pi0`), yaw (`ya23.025953`), and field of view (`fo100`).
-
-I think `ro0` refers to the roll value (my assumption is that Google images omit this value because roll is accounted for by Google pre-upload and thus always equal to 0).
-
-I have no idea about what `k-no` defines though.
-
-Now, one final Street View image to use as a comparison, this time another piece of user contributed imagery, this time from Federico Debetto, and the Zanzibar Street View project:
-
-
-
-`https://www.google.co.uk/maps/@-6.2159039,39.2119878,3a,75y,4.95h,93.34t/data=!3m8!1e1!3m6!1sAF1QipNZxgmALRIjjkbvUWBAOJYLi6niVs3pCosZ5ul3!2e10!3e11!6shttps://lh5.googleusercontent.com/p/AF1QipNZxgmALRIjjkbvUWBAOJYLi6niVs3pCosZ5ul3=w203-h100-k-no-pi-18.636326-ya45.429626-ro-1.5321815-fo100!7i7680!8i3840`
-
-_Decoded URL, hence will not load correctly._
-
-```
-data=
-!3m8
-!1e1
-!3m6
-!1sAF1QipNZxgmALRIjjkbvUWBAOJYLi6niVs3pCosZ5ul3
-!2e10
-!3e11
-!6shttps://lh5.googleusercontent.com/p/AF1QipNZxgmALRIjjkbvUWBAOJYLi6niVs3pCosZ5ul3=w203-h100-k-no-pi-18.636326-ya45.429626-ro-1.5321815-fo100
-!7i7680
-!8i3840
-```
-
-Compared to the Trek View user uploaded image analysed previously, this time the 4th (`!1sAF1QipNZxgmALRIjjkbvUWBAOJYLi6niVs3pCosZ5ul3`
-), 7th (pano info), 8th (`!7i7680`) and 9th (`!8i3840`) bangs differ.
-
-And I give up.
-
-I'm not sure my own trial and error is getting me any closer to becoming _fluent_ in Street View URL bangs!.
-
-My guess is that some of these bangs refer to my Google account and other user specific variables (like browser, device, type of Google Maps app...) in addition to the image location.
-
-Hopefully some enterprising reader might be able to help me complete this puzzle...
\ No newline at end of file
diff --git a/_posts/2020-01-10-underwater-google-street-view.md b/_posts/2020-01-10-underwater-google-street-view.md
deleted file mode 100644
index cde965d..0000000
--- a/_posts/2020-01-10-underwater-google-street-view.md
+++ /dev/null
@@ -1,132 +0,0 @@
----
-date: 2020-01-10
-title: "Underwater Street View"
-description: "The challenges we've faced and resulting solutions when capturing underwater 360-degree tours."
-categories: guides
-tags: [Google, Street View, 360Bubble, HoudahGeo, GPS, dive, GoPro, Fusion, Max, Ricoh, Theta, Garmin, Virb, Samsung, Gear 360, Insta360, ONE]
-author_staff_member: dgreenwood
-image: /assets/images/blog/2020-01-10/street-view-underwater-meta.jpg
-featured_image: /assets/images/blog/2020-01-10/street-view-underwater-sm.jpg
-layout: post
-published: true
-redirect_from:
- - /blog/2020/underwater-google-street-view
----
-
-**The challenges we've faced and resulting solutions when capturing underwater 360-degree tours.**
-
-Unusual creatures, amazing geological features, sunken treasure...
-
-Our oceans are amazing places.
-
-Despite this,
-
-> More than eighty percent of our ocean is unmapped, unobserved, and unexplored. Much remains to be learned from exploring the mysteries of the deep
-
-[As reported by the National Ocean Service (US)](https://oceanservice.noaa.gov/facts/exploration.html).
-
-Knowing the GoPro Fusion's on our Trek Packs are waterproof, we took a boat out to sea to start shooting.
-
-Though we quickly ran into problems...
-
-## Water changes the effect of light
-
-**Problem**
-
-Without going _too deep_, having water directly on the GoPro Fusion's causes light refraction issues.
-
-Light behaves differently in water and differences in light on either side of the camera cause issues during stitching, including stitch lines in the photo and focus problems (blurring of photo).
-
-To solve these problems, a clear barrier between the water and camera is required. The cleanest way to achieve this is with a "fishbowl design".
-
-**Solution**
-
-[Introducing the 360 Bubble](https://360bubble.co/).
-
-
-
-It's suitable for GoPro Fusion, GoPro Max, Ricoh Theta S/V, Samsung Gear 360/Gear 360 2017, Garmin Virb, Insta360 ONE, Nikon Keymission 360 and many other consumer 360 cameras and rated for use to a depth of 10 metres.
-
-The downsides; it's a little bulky to put in your hand luggage (and requires a hard case when placed in checked luggage). And the price.
-
-## GPS does not work underwater
-
-**Problem**
-
-GPS does not work underwater, especially in salt-water.
-
-The reason; radio signals do not propagate very far underwater. The heavy salt-water just makes this worse.
-
-Take a GPS receiver, place it just 30 cm underwater, and it'll probably lose its lock on to any GPS satellites.
-
-Despite the GoPro Fusion being waterproof rated to 10m, this does not include GPS functionality.
-
-This means you'll need a receiver on the surface to capture a GPS track of your dive.
-
-As always, we needed a cheap and easy solution.
-
-**Solution**
-
-
-
-After some experimentation we used a swim buoy with a GPS receiver watch inside it tied to the diver using a dive rope (we were diving in an open area).
-
-We chose a cheap [swim buoy](https://www.amazon.co.uk/gp/product/B07DDCMYYZ/) and [GPS receiver with a good chipset](https://www.amazon.com/Columbus-P-1-Professional-Data-Logger/dp/B07MD6TWW9). You could also use a smartphone to track the surface GPS log (we were a little worried about getting ours wet!).
-
-Don't worry about placing the GPS tracker in the dry buoy -- [GPS will work through plastic](https://blog.mapspeople.com/gps-the-complete-guide).
-
-On the boat we turn on the GoPro Fusion, setting it to 5 second timelapse mode without GPS.
-
-When the diver gets in the water, we turn on the watch to capture location every second.
-
-As the diver moves in the water, they keep the buoy string tight to keep it as close to overhead as possible.
-
-It's not perfect, and does not capture depth (we're currently experimenting with dive watch data) but works surprisingly well when out in the harsh conditions of the ocean.
-
-The only issue we've suffered is the camera overheating in the bubble after around 2 hours of continuous shooting (due to the lack of airflow in the 360 Bubble). We've found no solution to this issue yet, and know all housings will suffer the same issue.
-
-## Photo EXIF data and GPS data are separate
-
-**Problem**
-
-After capturing the photos and GPS track, you'll need to geotag the photos (add GPS co-ordinates to photos EXIF data).
-
-Even 1 minute of footage (at 5 second timelapse) will produce 12 photos that need to be geotagged.
-
-[Luckily there are lots of software tools that can automate the geotagging of images](https://havecamerawilltravel.com/photographer/geotagging-software/).
-
-**Solution**
-
-
-
-[We use HoudahGeo 5](https://www.houdah.com/houdahGeo/) to geotag our photos and believe it is well worth the $50 price tag (there is a free trial).
-
-The geotagging process is fairly straightforward and HoudahGeo 5 gives you an enormous amount of control over the geotagging process.
-
-GoPro Fusion studio looks for GPS co-ordinates in the front images (identified by prefix `GF`), therefore you need to geotag only the front facing images.
-
-For our requirements, we set HoudahGeo 5 to match the time of the photo to the timestamp of GPS co-ordinates for geotagging. Clearly this means that it is vital the camera and GPS receiver clocks are in-sync (although HoudahGeo does allow you to correct time offsets between devices if they deviate -- a very useful feature).
-
-## Google Street View does not support underwater photos
-
-**Problem**
-
-This is not true. Google Street View does support underwater 360-degree photos.
-
-**Solution**
-
-
-
-[Here are some of the dive sites already captured on Google Street View to inspire you](https://www.google.com/streetview/gallery/#oceans/).
-
-Many of these were captured by [the Underwater Earth team](https://www.underwater.earth) (who inspired this post -- [check out their cameras](https://www.underwater.earth/gallery)!).
-
-## Become a Trekker
-
-Our oceans are changing quickly.
-
-From temperatures bleaching coral reefs to plastic pollution collecting in giant "garbage patches".
-
-We need to do a lot more to protect our oceans, and that starts through education.
-
-Help us capture underwater images to inspire others to get involved in marine conservation efforts and keep a record of our oceans health.
\ No newline at end of file
diff --git a/_posts/2020-09-18-playing-with-mapillary-api.md b/_posts/2020-09-18-playing-with-mapillary-api.md
deleted file mode 100644
index cc6fd9e..0000000
--- a/_posts/2020-09-18-playing-with-mapillary-api.md
+++ /dev/null
@@ -1,310 +0,0 @@
----
-date: 2020-09-18
-title: "Playing with the Mapillary API"
-description: "A quick look at some of the API queries we've used against the Mapillary API."
-categories: developers
-tags: [Mapillary, object detection]
-author_staff_member: dgreenwood
-image: /assets/images/blog/2020-09-18/mapillary-object-detections-meta.jpg
-featured_image: /assets/images/blog/2020-09-18/mapillary-api-object-detections.jpg
-layout: post
-published: true
-redirect_from:
- - /blog/2020/playing-with-mapillary-api
----
-
-**A quick look at some of the API queries we've used against the Mapillary API.**
-
-[Mapillary's Chris Beddow wrote a brilliant blog post about getting started with the Mapillary API](https://blog.mapillary.com/update/2020/08/28/map-data-mapillary-api.html).
-
-I wanted to add some of our favourite API requests for uncovering interesting data.
-
-We recently ran a mapping party in the New Forest, UK.
-
-The photos are great to explore interactively to get a feel for the visual beauty of the area.
-
-A location can be requested via the Mapillary API using a bounding box (`bbox`).
-
-There are lots of tools to calculate coordinates for a bounding box programmatically.
-
-A useful web tool for doing this is [boundingbox.klokantech.com](https://boundingbox.klokantech.com/).
-
-
-
-A bounding box is a rectangular box that can be determined by the x and y axis coordinates in the upper-left corner and the x and y axis coordinates in the lower-right corner of the rectangle.
-
-In mapping terms we can use latitude and longitude for position.
-
-```
-bounding_box=[min_longitude,min_latitude,max_longitude,max_latitude.]
-```
-
-My bounding box for the New Forest is:
-
-```
-bounding_box=-1.774513671,50.7038878539,-1.2966083975,50.9385637585
-```
-
-You'll notice I drew a polygon on the map, that was converted to a rectangle. This is because bounding boxes are always rectangular. Bounding polygons do exists, but the Mapillary API search endpoints not accept them.
-
-Important note: I would not typically use a bounding box this large against the Mapillary API, especially when a large volume of images are likely (e.g. in cities) because such a query will be slow and prone to errors.
-
-I'd recommend:
-
-1. resize your bounding box (and make smaller systematic requests across an area) or,
-2. in the case of our mapping party where we know some variables, you can use other parameters instead of bbox to filter images, like `image_keys`, `organization_keys`, `userkeys`, `usernames`, `start_time` or `end_time` where these values are known, then filtering images locally on your machine after getting a response.
-
-Now we know where we want to analyse, we can run some queries against the Mapillary API.
-
-[I will assume you've already read Chris' post which will show you the basics of forming a request to the Mapillary API](https://blog.mapillary.com/update/2020/08/28/map-data-mapillary-api.html).
-
-One thing to note, you'll see I use the `per_page=500` in my requests. This is saying, only show 500 records in the response and then paginate. In many cases, more than 500 total records will be returned. In which case you can increase to the maximum records allowed `per_page=1000` (it will be slower, and potentially still to small) or use some logic to iterate through each page.
-
-## Object detections vs. features
-
-First it's important to distinguish between object detections and features in Mapillary.
-
-
-
-[Object detections](https://help.mapillary.com/hc/en-us/articles/115000967191-Object-detections) are areas (x,y,x,y,x,y... co-ordinates) of an image that have been detected as a certain object. For example, you can see each pixel in the above image corresponds to an object detection, like a car or road surface.
-
-Whereas features can be thought of as single points on a map. For example, a car has been detected (by Mapillary object detections) in an image and has been assigned a real world latitude and longitude value.
-
-
-
-[Mapillary features](https://help.mapillary.com/hc/en-us/articles/115002332165) use multiple photos to determine an objects position using triangulation.
-
-For example, 3 images contain a photo of a car. Using the position of each of those photos (latitude and longitude reported in metadata), Mapillary can estimate the actual position of the car and then assign it to that feature. As such, features will usually have different co-ordinates from the images used to detect it.
-
-In the last image above, I've tried to demonstrate an object (traffic light) being identified in 6 images from which a features position has been determined.
-
-### Wildlife (object detections)
-
-Let's start with the [`object_detections`](https://www.mapillary.com/developer/api-documentation/#object-detections) endpoint so we can identify photos that contain wildlife of some sort.
-
-Wild ponies can be found all over the New Forest and are a draw for visitors. Being so close to the coast, it's also a great place for bird watching. Let's take an _automated_ look, for them (`animal--bird&animal--ground-animal`):
-
-```
-curl "https://a.mapillary.com/v3/object_detections/segmentations?client_id=Overview
-Since the inception of Trek View I've wanted to build a map platform similar to Street View, but designed for adventurers.
I have over 100 terabytes of footage on the map, it's just incredibly hard to search and share.
@@ -22,7 +20,7 @@ redirect_from:Now I am building it.
-What's wrong with Street View or Mapillary?
+What's wrong with Street View or Mapillary?
Nothing.
@@ -36,15 +34,15 @@ redirect_from:The assumption is you know where you want to drop into the imagery. For looking up what a store front looks like from an address, or if parking is easy, Mapillary and Street View are perfect. For trails, finding viewpoints or way-markers is more important which you can't easily get an address or fixed point to search on.
-What are the challenges with building a street level image map?
+What are the challenges with building a street level image map?
What seems like a fairly simple tool, a map with images you can drop into, unravels to be very complex (and expensive) once you get under the hood...
-Data types/size
+Data types/size
My backup of GoPro imagery and video is more than 100 Tbs, and growing quickly. That is just imagery I've shot!
-To give a basic storage estimate using [Amazon S3 storage](https://aws.amazon.com/s3/pricing/) (I know there are cheaper options), it costs $0.023 per GB for storage. So $0.023 * 30000 = $690/mo!
+To give a basic storage estimate using [Amazon S3 storage](https://aws.amazon.com/s3/pricing/) (I know there are cheaper options), it costs $0.023 per GB for storage. So $0.023 * 100000 = $2300/mo!
These services also charge for bandwidth usage. For example, you pay for requests made against your S3 buckets and objects. Assuming a user views 30 or 40 images per session, the costs get huge!
@@ -54,7 +52,7 @@ redirect_from:For someone with a budget of less than $100/mo to run this, following the approach of hosting all the data myself is impossible.
-Database storage
+Database storage
This is where the complexity can come in. In Street View you have interconnected blue lines. You can jump between images seamlessly in the interface.
@@ -64,7 +62,7 @@ redirect_from:With time, these queries and processing logic can be tuned, but working spacial data is tough (at least for someone that doesn't work full-time in this area).
-User interface
+User interface
Viewing a single 360 in a panoramic viewer like [Panelleum is easy](https://pannellum.org/).
@@ -76,7 +74,7 @@ redirect_from:In short, trying to build this from scratch to a level that would be acceptable for a user would not be easy.
-My hacky plan...
+My hacky plan
I'm used to working with limitations like this, and quite enjoy it.
@@ -89,33 +87,48 @@ redirect_from:With this in mind, I am using Mapillary as a backend as follows...
+With this in mind, I decided to use Mapillary as a backend as follows...
-
-
- allow user to upload photos or videos via a Trek View web application to Mapillary -
- the Mapillary processed metadata for each sequence uploaded is stored in Trek View web application -
- a user views images in Trek View web application (the images themselves are loaded from Mapillary servers) +
- allow user to upload photos or videos via a Trek View web application direct to Mapillary +
- the Mapillary processed metadata for each sequence uploaded is stored in Trek View web application, but the actual images live on the Mapillary server +
- a user requests images using the metadata stored in the Trek View web application database, but the images themselves are loaded from Mapillary servers (the URL of which lives in the metadata inside the Trek View database)
From here I can do neat things like:
+The massive risk of this plan
--
-
- Allow users to group sequences into larger ones (e.g. to create an entire trail) -
- Expose a search and filter on the map -
- Show weather, air quality, etc for each image (and also expose via search) -
- Use "adventure" specific views, including elevation, length of sequence, descriptive info, etc. -
The obvious risk with this plan, and I hate it, is that Facebook (aka Mapillary) can kill this product at anytime.
-Here are some mockups I've created to try and illustrate what I have in my mind;
+If Facebook shut-down Mapillary entirely or simply stop allowing users to upload or retrieve images for free my product is dead in the water.
- +As this is a hobby project which I'm quite happy to use as a learning experience I am reluctantly happy to overlook this issue. However, I do expect to wake up one day for my map to be broken. To be clear, if this was a commercial project, I would not proceed any further with this approach (I'm putting this warning here for the many I have spoken to considering some form of competing commercial product to Street View or Mapillary. You have been warned!).
-The massive risk of this plan
+The proposed app
-The obvious risk with this plan, and I hate it, is that Facebook (aka Mapillary) can kill this product at anytime.
+Once I have this data in a database I can build neat features on-top of it including:
-If Facebook shut-down Mapillary entierly or simply stop allowing users to upload or retrieve images for free my product is dead in the water.
+Adventure specific search
-As this is a hobby project which I'm quite happy to use as a learning experience I am reluctantly happy to overlook this issue. However, I do expect to wake up one day for my map to be broken. To be clear, if this was a commercial project, I would not proceed any further with this approach (I'm putting this warning here for the many I have spoken to considering some form of competing commercial product to Street View or Mapillary. You have been warned!).
+
Search and filter sequences you want to see. Filter by the activity. Filter by the time of year they were captured. Filter by the weather...
+ +Enrich sequences
+ +Add additional metadata to each sequence, including weather and air quality, sowing this to the user when viewing a sequence, and also exposing it via search.
+ +More intuitive navigation of imagery
+ +
Using trail specific views, including navigating the images in a sequence by elevation.
+ +Grouping of sequences
+ +
Image taken from Ride with GPS
+ +Allow users to group sequences into larger ones (e.g. to create an entire trail) and add descriptive information to aid users considering visiting the trail themselves.