The idea to map radars and mirrors of the Czech highways was raised in the mailing list of the Czech community. One of the comments is questioning about how to track the work done–and that’s exactly the problem to be solved by the damn project. (Note that the idea to map radars and mirrors of the Czech highways is still just an idea and there are no further steps done yet I’m aware of.)
I already wrote two Get inspired by … diaries. These were the potential HOT tasking manager improvements and the Tanga Building Footprints Import. This diary discuss the use of the damn project for tracking the work done on highways.
The damn project helps mappers by dividing some big area into smaller squares that a human can map. How this applies to highways?
It’s possible to upload two kinds of GeoJSON boundary files to the damn
manager. If the FeatureCollection has member ‘name’ then divide to squares
function is NOT used. Moreover, I’ve updated the damn project to understand
what to do with a feature containing a
LineString geometry: create a
“square” with the border around the
LineString. (“Square” here means a square
of an area of the damn project.)
So… when you download some
highway=motorways within some interesting
bounding box (I mean from overpass API in JOSM,) save as GeoJSON, and add
member, you are able to upload that as GeoJSON boundary file to the damn
Note that I experimented with joining ways to make larger squares of an area. The JOSM damn plugin then refused to automatically download the OSM data of a square because the square was too large, and the data had to be downloaded manually.
The mappy client may help to visualize the area. An example is area 2352 and it looks way better with background image switched off. The JOSM damn plugin, light client, or panel using map random square/map nearest square are better options, though.
Yet one minor update to the damn project is to splitting of the squares. I added split horizontally and split vertically commit types that are currently possible in the mappy client. This is because splitting of a highway square led sometimes to tiny squares in the middle of the highway square. (Imagine highway from the left bottom to the right top of the square splitted to four sub-squares.)
It’s possible to track the work done for highways mapping. I know the damn clients could be (significantly) better. I still hope for someone to come and write their own client for the damn server API from scratch. That would be fantastic, at least because the development would become decentralized. Until then, the mappers have no option than suffer from my design.
And that’s about tracking the work done on highways. I wonder if logging the data and importing them with the idea of the last get inspired by … diary wouldn’t be a better option for this particular project.