Build upload workflow
lxbarth opened this issue · 17 comments
Create a light HTML web site guiding the upload workflow
- Should have a map like http://a.tiles.mapbox.com/v3/lxbarth.map-2hiyqfkx/page.html#12/38.9079/-77.0140
- Click on census block (NOTE: #12) to download an address and a building file
- One-pager document on how to review and upload file with JOSM
Your second step can be automated a little bit with the remote control feature in JOSM:
http://josm.openstreetmap.de/wiki/Help/Preferences/RemoteControl
It's not enabled manually (so the user would have to enable it before participating), but it would allow a single-click "get your JOSM set up" action from the map after that. This might facilitate repeat users.
This is basically what the Tasking Manager does. It builds an interface where a user can check out a task, and mark it as complete when done. Completion of entire Job can be tracked. There's a validation step too.
For the TM to do this would require, I think, a small modification to the "Tile" model, and a new job creation process.
hotosm/osm-tasking-manager#142. The basic idea is to define Tiles not exclusively by z/x/y, but by arbitrary polygon.
JOSM remote control is built in already. We'd just need to modify that link to open the associated address and building file. That association can also be stored in the Tiile model
Quick test to see if TM can handle arbitrary geometries. This is a screen shot from a tasking manager job, with task boundaries defined by DC Census blocks.
http://i.imgur.com/3CqxivH.png
Taking, committing, and validating tasks all works as expected. Need to smooth out a few rough edges, set up job creation interface, associate osm files with task, etc. But from what I'm seeing, TM can fill this role with just a few more minimal improvements.
Awesome!
On Aug 11, 2013, at 5:02 PM, Mikel Maron notifications@github.com wrote:
Quick test to see if TM can handle arbitrary geometries. This is a screen shot from a tasking manager job, with task boundaries defined by DC Census blocks.
http://i.imgur.com/3CqxivH.png
Taking, committing, and validating tasks all works as expected. Need to smooth out a few rough edges, set up job creation interface, associate osm files with task, etc. But from what I'm seeing, TM can fill this role with just a few more minimal improvements.
—
Reply to this email directly or view it on GitHub.
@MateoV - over to you. Let's figure out whether OSM Tasking manager is a viable option here with the DC buildings export first (rather than using nycbuildings) as we have all data in place and transformed.
@mikelmaron if you need any help with the OSMTM changes let me know
I would be really happy to have this feature integrated in the tasking manager. @mikelmaron, it looks like you have already hacked the tasking manager successfully.
Just in case, you may also be interested in taking a look at http://mapcraft.nanodesu.ru/. They already support arbitrary geometries.
I think this is the way to go. The tasking structure is already in place, the community uses it, and it looks like integrating what we need is very possible. This is a good opportunity to expand OSMTM while assisting the DC/NYC imports.
Ideally we keep this a simple as possible and stick to the bare necessities for these imports to start. Workflow would be:
- At job creation the user is given the ability to split tasks into a grid or use existing geometry when uploading a GeoJSON (tracking here: hotosm/osm-tasking-manager#142)
- If existing geometry is used, present an option to link tasks to files for import
- based on property in GeoJSON (in dcbuildings, for example,
TRACTis the property that gets appended to the filenames)
- based on property in GeoJSON (in dcbuildings, for example,
- If task=import, make JSOM the only available editor & generate remote control link.
- Can two files be loaded at once this way?
I will have bandwidth to help with implementation after next week.
MateoV, awesome. Maybe good next steps are for us all to keep discussing here, and then meet up next week to make a plan to implement.
On 1, let's first decide the right model. Here's my quick hack:
mikelmaron/osm-tasking-manager@18a8570
also worth looking at the freehand branch.
https://github.com/hotosm/osm-tasking-manager/tree/freehand/OSMTM
2, what about a way to do this in a generic fashion. perhaps a set property name that OSMTM expects, which includes the full link of the OSM data.
3, that could just be a flag on the Job model, and easy enough to filter the available editors.
I don't think JOSM currently supports multiple files. Would it be possible to combine them, and only load one? I may have missed why they are split up, elsewhere.
Any progress on the osmtm changes ? I'd like to get them deployed and an hence quite motivated to assist with revisions
wrt JOSM, IMHO it would be beneficial to implement a method to execute multiple layer loads for a given task, as then a buildings, address point and base data layer can all be loaded for an editor via s single click. Even if all task related data is a single layer, the base data still needs to be loaded.
@oldtopos @mikelmaron @pgiraud
Spent a couple days integrating the basic functionality into osmtm using Mikel's hack as a starting point. Right now it works for what we need it for.
MateoV/osm-tasking-manager@41db7ef
- Added an optional "GeoJSON URL" field to the job creation page that will override the grid creation with the geometry from the remote file.
- Looks for a
import_urlproperty in the geojson and if it exists passes it to the Tile object. - If
import_urlexists for a task, adjust the first step to first download OSM data into JOSM, then import the remote .osm. @oldtopos It would be nice to do this in one click but not sure if it is possible with remote control.
/cc @lxbarth
@MateoV excellent!
Is this going to work, to load in a single external OSM file? I thought, but didn't understand why, there was a separate building and address file for the import? If multiple files are required, guess the import_url field could have a seperator.
If it's ok how it is, I guess we can do a pull request?!
For deployment, @mvexel and @iandees were setting up an instance of the OSMTM last week to try some things out. Not sure where that server was (ec2?). But I guess this server would be all set to deploy this version.
I've got vanilla OSMTM running on the osm.us server here: http://tasks.openstreetmap.us.
Happy to move over to this fork as long as the existing grid-based process is supported.
Is this going to work, to load in a single external OSM file?
The buildings and address files are now combined. There was no practical reason to keep them separated other than it was simpler to script.
Happy to move over to this fork as long as the existing grid-based process is supported.
The default grid works just as before if no geojson is specified.