Utilize the 2018 data in the imagery basemap

[Samuel Valdez]

DATA :: IMAGERY :: MAP :: UI :: UX :: VM WEB

---

• Target: 2018-12-18-T
• Target: 2019-01-15-T
• Actual: 2019-01-15-A

---

The URL to the available tiled imagery services is http://tile.sfgis-svc.sfgov.org/

The URL to the 2018 data (as a tiled imagery service) is http://tile.sfgis-svc.sfgov.org/v2/p2018/${z}/${x}/${y}.png

Note that the revision of the file (that is in the production environment) in which this URL is specified is not captured in the repository, so this enhancement includes committing the deployed revision of this file before committing it a second time with the 2018 URL:

Commit (SF PROD WEB) /var/www/html/eas/Media/js/MAD/widgets/MAD-widgets-Map.js to https://bitbucket.org/sfgovdt/eas/src/default/Media/js/MAD/widgets/MAD-widgets-Map.js

---

Please see service request SER0199391 for more information, and issue #159 for some historical context.

[Samuel Valdez]

Captured the revision of this file that is currently in production because it was not committed previously. This file is going to change again shortly (see #246), so do not worry about trying to repair the current release (1.3.6) at this time.

→ <<cset 8b6942b9ac90>>

[Samuel Valdez]

Earlier today, @bbq_ declared that level 22 was "about 80% done".

[Brian B. Quinn]

Hi Sam, That's so three-hours-ago. It's showing 90% done now! But that's just the Level 22 image alone. The first time through, I didn't manually generate Level 22, and our native 76mm/3-inch pixels actually are a very close fit for Level 21. When I did generate a Level 22, I didn't treat it properly like a resampling, and I got nearest-neighbor default resampling that wasn't as good as QGIS was doing dynamically. So I re-ran on GDAL using cubic convolution, which got to 95% done and then hung after five days! Now I'm running a more typical bilinear resampling, and that is very likely to finish and also look noticeably higher quality than the nearest-neighbor one did.

But after that's done, I'll still need to run 'gdaladdo' to add the overlays, a.k.a. pyramids, all the way up to level 4 or something. Because each level is 1/4 the size of the one below it, that's actually only going to take a couple of days to run. This Level 22, when it completes properly, takes about five days because it's growing three bands of our four-band image from 90 GB into 360 GB. Then the pyramiding will add another 200 GB or so onto that for the final Mapblock Tiles product. Meanwhile, I'll be exploring GeoServer 2.14 on our test server to see how we might serve up other formats besides .mbtiles---as long as we can maintain the excellent performance that we get. On the other hand, the tile server works exceedingly well for QGIS users, so if they benefit, together with EAS users indirectly, it's probably still worth all this trouble. And each year that my notes get refined the process goes a little bit faster. The first time around, in 2015 for the 2014 photo, it took me about 30 days to get it right. -=Brian Q

[Brian B. Quinn]

The Level 22 resample has finished, and although bilinear is not as sharp-looking as the cubic convolution that I first tried, it's definitely better than the nearest-neighbor that it replaces.

The five-day process that just completed was this

gdal_translate -ot Byte -of MBTILES -b 1 -b 2 -b 3 -r average -a_nodata 255 -co "MINZOOM=8" -co "MAXZOOM=22" sf13_p2018c.vrt p2018.mbtiles

Pyramid construction is underway using:

gdaladdo --config COMPRESS_OVERVIEW DEFLATE -r cubic p2018.mbtiles 2 4 8 16 32 64 128 256 512 1024 2048 4096 8192

[Samuel Valdez]

Pending completion of building the Level 22 images.

[Brian B. Quinn]

looks good.

http://tile.sfgis-svc.sfgov.org/v2/p2018_rgb76mm/{z}/{x}/{y}.png

[Samuel Valdez]

The tiled imagery service is now available, though the URL has changed slightly:

• WAS: http://tile.sfgis-svc.sfgov.org/v2/p2018_rgb76mm/${z}/${x}/${y}.png
• IS.: http://tile.sfgis-svc.sfgov.org/v2/p2018/${z}/${x}/${y}.png

[Samuel Valdez]

To compare with the 2018 imagery.

[Samuel Valdez]

To compare with the 2017 imagery.

[Samuel Valdez]

Fixed in → <<cset 0485057b0593>>

Deployed to the development environment and tested. Note that in the lower right-hand corner of the 2018 attachment, a portion of one of the cranes (reddish) is visible to support the construction that was not started in 2017.