-
Notifications
You must be signed in to change notification settings - Fork 48
Bundle osrm-components with node-osrm #283
Comments
Yeah we don't bundle it because we don't want to depend on One way around this would be to let |
Yes, we could support libgdal in the mason build (there are mason packages for gdal) but @TheMarex and I decided not to. I'm still in support of this because gdal is a large download and would slow down the mason fetch. I also agree that the best route forward is to target geojson in |
Another alternative: I've used this, it works. The shapefile format is significantly smaller than a GeoJSON output would be. For our use case, we would only need a very simple wrapper. |
Let's keep the discussion here free of upstream decisions, we already have which outlines pros and cons of going the GeoJSON way. |
Project-OSRM/osrm-backend#3570 just landed upstream unblocking us from bundling |
The use case came up to quickly iterate on components and a modified profile making use of the shapefile generated by
osrm-components
. At the moment we do not bundleosrm-components
mainly because it is an internal tool, we run it on the demo server anyway, and there is the debug map rendering components in real-time.Can we bundle
osrm-components
easily with this package for npm?What I can see on the osrm side is components not being supported by the mason build? Is this because of libgdal? @springmeyer any insights here - what's your take on this ticket?
cc @geohacker @srividyacb @oini
The text was updated successfully, but these errors were encountered: