search

osmlab / dcbuildings

Restart that ole DC building footprint + address import
7 stars 8 forks source link

Build upload workflow #19

Closed lxbarth closed 11 years ago

lxbarth commented 11 years ago

Create a light HTML web site guiding the upload workflow

iandees commented 11 years ago

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.

lxbarth commented 11 years ago

@iandees - good call.

mikelmaron commented 11 years ago

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. https://github.com/hotosm/osm-tasking-manager/issues/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

mikelmaron commented 11 years ago

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.

lxbarth commented 11 years ago

Awesome!

http://twitter.com/lxbarth

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.

lxbarth commented 11 years ago

@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.

oldtopos commented 11 years ago

@mikelmaron if you need any help with the OSMTM changes let me know

mikelmaron commented 11 years ago

@oldtopos thanks! Want to hear from @lxbarth and @MateoV if this strategy will work for the import. Then we can look in more detail at what's needed, loop in @pgiraud to discuss the best implementation option.

pgiraud commented 11 years ago

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.

MateoV commented 11 years ago

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:

  1. 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: https://github.com/hotosm/osm-tasking-manager/issues/142)
  2. If existing geometry is used, present an option to link tasks to files for import
    • based on property in GeoJSON (in dcbuildings, for example, TRACT is the property that gets appended to the filenames)
  3. 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.

mikelmaron commented 11 years ago

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:

https://github.com/mikelmaron/osm-tasking-manager/commit/18a8570c6f79cb24fb5c822f162247ad4bbaa88b

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.

oldtopos commented 11 years ago

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.

MateoV commented 11 years ago

@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. https://github.com/MateoV/osm-tasking-manager/commit/41db7ef75c462005326933bb1328e1d2e4fc75c4

  1. Added an optional "GeoJSON URL" field to the job creation page that will override the grid creation with the geometry from the remote file.
  2. Looks for a import_url property in the geojson and if it exists passes it to the Tile object.
  3. If import_url exists 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.

osm tasking manager - job - dctest

/cc @lxbarth

mikelmaron commented 11 years ago

@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.

iandees commented 11 years ago

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.

MateoV commented 11 years ago

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.

lxbarth commented 11 years ago

Awesome. Next actions:

Closing here.