npm i fails if node-mapnik binaries aren't available for arm/arm64/win-x86
#132
Labels
documentation
Improvements or additions to documentation
Comments
|
I had the same issue. Solved it by adding this docker image of spritezero to Makefile Though I don't know how essential Mapnik is for the sprite sheet generation. Could spritezero be forked, Mapnik removed and would it still run? |
|
Browsing through NPM, https://www.npmjs.com/package/sharp seems to be able to rasterize an SVG and provides binaries for a sufficient number of architectures. Or this: https://github.com/yisibl/resvg-js |
|
It turns out that I also tried to ensure that Maybe alternate ways of tackling this like @Mashin6 and @jleedev suggest would be better... @Mashin6 , what other steps did you need to take to get the docker alternative for spritezero working? I'm imagining that installing docker is part of it, but not sure beyond that. ;-) |
|
From the start, I did: I hope I didn't forget anything. |
|
Note that xmlstarlet should no longer be needed, now that we've removed the SVG transformation code from when we were importing rebusurance shields. |
|
Sweet, crossing that out.. |
|
@jleedev Looking into spritezero, there are two places Mapnik is used:
If sharp could do both then there would be a way to switch the backend. |
|
@adamfranco Also I just realized that x64 binaries should be able to run through rosetta. So a possibility is to install Rosetta and run bash in x64 mode |
|
Thanks @Mashin6! that worked for me! Here's the process I used to get First I made a duplicate of Terminal set to open with Rosetta as described here: https://www.courier.com/blog/tips-and-tricks-to-setup-your-apple-m1-for-development/ Then I followed these instructions to install an LTS version of nvm tied to x64: https://gist.github.com/LeZuse/bf838718ff2689c5fc035c5a6825a11c These commands are run under the Rosetta-Terminal. Note that my global install of node is for arm64, so I'm using nvm to get an x64 version installed temporarily. After this first install which downloads the node-mapnik binaries, it seems like further npm commands in the non-Rosetta amd64 version of npm work just fine. Removing the dependency might also be a decent option going forward, but this work around seems easy enough to at least get up and running on m1 right now. |
|
Awesome! |
|
I wanted to avoid standalone install of nvm and this worked for me as well. Normal Terminal Rosetta Terminal Normal Terminal |
|
I tried running the project natively on Windows, and got the same, or very similar error. Windows users can run on Linux via WSL, but it looks like removing this dependency would be beneficial for more than just those with Apple Silicon Macs. |
|
Can we confirm whether this is still an issue? If it's only a problem on one specific platform, let's update the issue title to reflect that. |
|
mapnik still doesn't have binaries for linux arm and arm64. |
|
Sounds like the issue has been confirmed on Linux arm, Mac arm, and Windows x86. The issue is not present on Linux x86 and Mac x86. |
ZeLonewolf
changed the title
npm i fails if node-mapnik binaries aren't available for the current platformnpm i fails if node-mapnik binaries aren't available for arm/arm64/win-x86
jleedev
added a commit
that referenced
this issue
Jun 7, 2022
Replace spritezero with the (just-released) [sprites], which uses the same [shelf-pack] logic but uses [sharp] for SVG rendering, which has the advantages of: - Provides [binaries] for several platforms (windows, macos, linux, linuxmusl) and architectures (arm64 and x64) - Fixes #132. - Compiles without a fuss on other platforms (e.g. 32-bit linux arm), unlike mapnik which is, shall we say, large. - Seems to render certain SVGs more correctly than mapnik. I haven't prepared a gallery, but there were obvious fixes in the area of antialiasing and downsampling. Of note, mapnik was inflating the stroke width in star_state_capital.svg and dot_city (if we liked those, we should adjust the stroke width in the actual icon). There are minor changes to dimensions due to rounding: ``` $ curl -fs https://zelonewolf.github.io/openstreetmap-americana/sprites/sprite.json | jq -c .shield40_us_oh_tus_salem {"height":19,"pixelRatio":1,"width":25,"x":283,"y":61} $ <style/dist/sprites/sprite.json jq -c .shield40_us_oh_tus_salem {"width":25,"height":20,"x":85,"y":221,"pixelRatio":1} $ head -n1 style/icons/shield40_us_oh_tus_salem.svg <svg width="25" height="19.999" version="1.0" xmlns="http://www.w3.org/2000/svg"> ``` As a result, the entire sprite sheet looks different, so a comparison is full of noise, but efforts to align SVGs to a pixel grid can be more useful now. [binaries]: https://github.com/lovell/sharp/releases [shelf-pack]: https://www.npmjs.com/package/@mapbox/shelf-pack [sharp]: https://www.npmjs.com/package/sharp [sprites]: https://www.npmjs.com/package/@basemaps/sprites
jleedev
added a commit
that referenced
this issue
Jun 7, 2022
Replace spritezero with the (just-released) [sprites], which uses the same [shelf-pack] logic but uses [sharp] for SVG rendering, which has the advantages of: - Provides [binaries] for several platforms (windows, macos, linux, linuxmusl) and architectures (arm64 and x64) - Fixes #132. - Compiles without a fuss on other platforms (e.g. 32-bit linux arm), unlike mapnik which is, shall we say, large. - Seems to render certain SVGs more correctly than mapnik. I haven't prepared a gallery, but there were obvious fixes in the area of antialiasing and downsampling. Of note, mapnik was inflating the stroke width in star_state_capital.svg and dot_city (if we liked those, we should adjust the stroke width in the actual icon). There are minor changes to dimensions due to rounding: ``` $ curl -fs https://zelonewolf.github.io/openstreetmap-americana/sprites/sprite.json | jq -c .shield40_us_oh_tus_salem {"height":19,"pixelRatio":1,"width":25,"x":283,"y":61} $ <style/dist/sprites/sprite.json jq -c .shield40_us_oh_tus_salem {"width":25,"height":20,"x":85,"y":221,"pixelRatio":1} $ head -n1 style/icons/shield40_us_oh_tus_salem.svg <svg width="25" height="19.999" version="1.0" xmlns="http://www.w3.org/2000/svg"> ``` As a result, the entire sprite sheet looks different, so a comparison is full of noise, but efforts to align SVGs to a pixel grid can be more useful now. [binaries]: https://github.com/lovell/sharp/releases [shelf-pack]: https://www.npmjs.com/package/@mapbox/shelf-pack [sharp]: https://www.npmjs.com/package/sharp [sprites]: https://www.npmjs.com/package/@basemaps/sprites
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I'm trying to set up americana on a new M1/arm64 Macbook, but found that installation is failing because the
mapnik-nodebinary doesn't exist for the arm64 architecture.The x64 binary exists:
https://mapbox-node-binary.s3.amazonaws.com/mapnik/v4.5.8/Release/darwin-x64.tar.gz
but the arm64 binary doesn't exist and triggers a custom build of :
https://mapbox-node-binary.s3.amazonaws.com/mapnik/v4.5.8/Release/darwin-arm64.tar.gz
Upstream issue: mapnik/node-mapnik#945
npm ifails with this error:Given the outstanding upstream issue, I'd suggest noting that
mapnikmight be needed in the installation docs just so other contributors don't have to track down this issue independently. Installingmapnikand all of its dependencies (at least via macports) takes forever, but at least is straight forward.I'll submit a PR once I confirm that
port install mapnikis the trick that allows the rest of the build to work.The text was updated successfully, but these errors were encountered: