The objective here is to add an optional, minimal overlay of OpenStreetMap data on top of satellite imagery sources within the task bounding box, to help contextualize location.
Screenshots
Note that some of the labeling is cut off. This is due to how tiles are generated - the renderer doesn't know about any spatial data in adjacent tiles that may have labels bleeding into the next tile. I don't know of a workaround for this; I've seen the same when exporting raster tiles from vector data in QGIS.
What I changed
initiateRendering now takes an additional openStreetMap boolean. If set to true, we call a new function requestOpenStreetMapData.
requestOpenStreetMapData takes the input bounds and requests OSM data from the Overpass API that intersect with the bounds.
It uses two new libraries to get the OSM data into a usable format: xmldom to convert the XML data to JSON, and osmtogeojson to convert to GeoJSON.
The function also filters out lines and points. I didn't think any OSM polygon data would be useful to overlay on top of satellite imagery.
We then save the GeoJSON in the tempdir sources.
generateStyle now checks for the boolean, and if true, generates a style that takes the GeoJSON as a source and styles lines, points, and layers. This is not very sophisticated at this time - I opted to style waterways, roads, and boundaries. All points of interest are styled the same.
Validations for the boolean - we want to make sure that the style is one of the unlabeled satellite imagery sources, and not one that already has vector data.
I added one integration test for the whole flow, and one unit test intended to probe the use of the libraries in requestOpenStreetMapData. Note that for the integration test, I opted to take a more robust approach and expect a file > 69632 bytes, which is the persistent filesize of an "empty" MBTiles database. Reason being that OSM data is updated daily so the bytesize of the final output will never be the same. I think we should probably do the same for some of the other tests that may have images that are updated semi-regularly.
CLI and Azure Storage Queue have been adapted to work with the new OSM boolean.
What I'm not doing here
As mentioned above, the styling of OSM data is quite rudimentary, but it worked for the geographies where I was testing (see screenshot). I would be interested if folks could test this functionality in other geographies and recommend styling tweaks on that basis.
Closes #36.
Goal
The objective here is to add an optional, minimal overlay of OpenStreetMap data on top of satellite imagery sources within the task bounding box, to help contextualize location.
Screenshots
What I changed
initiateRenderingnow takes an additional openStreetMap boolean. If set to true, we call a new functionrequestOpenStreetMapData.requestOpenStreetMapDatatakes the input bounds and requests OSM data from the Overpass API that intersect with the bounds.xmldomto convert the XML data to JSON, andosmtogeojsonto convert to GeoJSON.generateStylenow checks for the boolean, and if true, generates a style that takes the GeoJSON as a source and styles lines, points, and layers. This is not very sophisticated at this time - I opted to style waterways, roads, and boundaries. All points of interest are styled the same.requestOpenStreetMapData. Note that for the integration test, I opted to take a more robust approach and expect a file > 69632 bytes, which is the persistent filesize of an "empty" MBTiles database. Reason being that OSM data is updated daily so the bytesize of the final output will never be the same. I think we should probably do the same for some of the other tests that may have images that are updated semi-regularly.What I'm not doing here
As mentioned above, the styling of OSM data is quite rudimentary, but it worked for the geographies where I was testing (see screenshot). I would be interested if folks could test this functionality in other geographies and recommend styling tweaks on that basis.