Bundle sprites and font glyphs in frontend

[3nprob]

See# #43

TODO:

• nginx routing
• style config
• makefile update
• test on aarch64

[3nprob]

Resulting files in headway_nginx docker image:

/usr/share/nginx/html/assets/sprite.json
/usr/share/nginx/html/assets/sprite.png
/usr/share/nginx/html/assets/[email protected]
/usr/share/nginx/html/assets/[email protected]
/usr/share/nginx/html/assets/glyphs/NotoSans-[Regular,Bold,Italic]/*.pbf

[3nprob]

Works fine for sprites, fonts are present but haven't tested with the styles actually using these yet.

[3nprob]

App is now using the bundled assets.

[3nprob]

I am not super clear on exactly what should go where between tileserver and nginx and if serveAllFonts/serveAllStyles should be on or off.

Note that style template is now included at build rather than read from volume.

I get a couple of console errors like Error: Source layer "park" does not exist on source "openmaptiles" as specified by style layer "park". and Image "pedestrian_polygon" could not be loaded. Please make sure you have added the image with map.addImage() or a "sprite" property in your style. You can provide missing images by listening for the "styleimagemissing" map event..

Not network errors, though.

Maybe some mismatch?

[ellenhp]

I mentioned this in #43 but I don't like the idea of putting these mapbox dependencies into the frontend. I do all my frontend development outside of docker and I don't like the idea of a bunch of native code running outside of docker. It sounds like node-fontnik even installs some stuff system-wide during its own installation.

[ellenhp]

What we definitely could do though is use a second sub-image (I don't know what they're actually called, but those "builder" images) inside the nginx Dockerfile. Currently we have one builder that does the quasar build, we could have another that does the font/glyph building. Once it's moved outside of the frontend's dev dependencies, the frontend package will be unencumbered by those deps, and, the dev server can proxy requests to any assets in the static/ directory to the demo server. That way I'll be able to develop frontend on my arm64 system.

[3nprob]

Sounds reasonable!

[ellenhp]

Cool! I do like the idea of moving all this stuff to the nginx image though. The tileserver config.json.template can stay how it is in this PR if you don't want to touch it, but we should probably open an issue to pare it down to the bare essentials in the future. I'm not sure exactly what that would look like though and it is a very frustrating piece of software to configure in my experience. A very nice piece of tech, but I don't understand it.

[ellenhp]

Hey! Any progress here? It looks like you've been spelunking into the mapbox/mapnik dependencies, which I think I will need to do if I want to evaluate Mapbox Carmen for #50, so I thought I'd ask how it's going.

[3nprob]

So, the spritezero and especially mapnik projects and builds are quite messy and for now I think I will be abandoning getting the whole chain build from source, which I agree is kind of problematic. So practically these means that aarch64 support will have to be a separate effort. I do think that someone more familiar with cmake would be able to figure it out.

Are there alternatives to spritezero? mapnik does seem like it could end up being technical debt down the line.

Other than that, I'll see if I can clean this up in the following days, including moving the deps out of the actual final image.

[dBitech]

Yes it's possible to remove the mapnik dependency for sprite generation, see how sprites are handled Replace mapnik with sharp for SVG rendering it's pretty straightforward

[ellenhp]

Yes it's possible to remove the mapnik dependency for sprite generation, see how sprites are handled Replace mapnik with sharp for SVG rendering it's pretty straightforward

Thank you for pointing that out! This seems like a much more lightweight alternative.