hotosm / osm-tasking-manager2

Designed and built for Humanitarian OpenStreetMap Team collaborative emergency/disaster mapping, the OSM Tasking Manager 2.0 divides an area into individual squares that can be rapidly mapped by thousands of volunteers.
http://tasks.hotosm.org
Other
425 stars 156 forks source link

Polygons done with OSM road #254

Open FredM74 opened 10 years ago

FredM74 commented 10 years ago

J tried to do a task (TM) based on OSM Road (polygons).

grid-basedonroad

But at the end rather than to follow my polygons, the TM generated his own grid taskmanager_grid

In JOSM, I have some error when I am trying to upload my digit

dissuad messagejosm

See the job I am trying to do http://tasks.hotosm.org/project/610

As I said since Haiti 2010, it is VERY important to be able to make a grid based on OSM road. rather than a grid.

So now I will start with a general grid.

http://tasks.hotosm.org/project/611

All the best FredM

AndrewBuck commented 10 years ago

I actually worked on one of these tasks and I don't think it was actually a problem. The only issue I had was that since the polygons for the boundary were exactly along the road centerlines, they were not visible below the main data layer. When I switched to the 605.osm layer though I did see the polygon from the task manager. It might be desireable to be able to "negative buffer" in the polygons, (i.e. negative buffer distance so they shrink in about 10 meters or so) so that they don't fall exactly on the road centerlines. This would have to be done in QGIS I think before uploading to the task manager as something like this would likely be too difficult to code as an option on the TM itself.

The reason you are getting the square download areas is because josm and the osm server itself can only do rectangular bboxes so you are getting the bbox around the road square, rather than the exact road square.

As for the warning on upload I think that is the 'upload discouraged' warning (I don't speak French). If it is then it is related to issue #251 and is a separate thing.

FredM74 commented 10 years ago

Thank you very much Andrew, I realize normally buffers on the roads to achieve my polygons. And it was the solution for the tasking manager, thank you for having responded as precisely, this is an huge help for the next time.

pgiraud commented 10 years ago

I'm glad to see that you tried to create a project using the new "arbitrary polygons" mode. This project was a good candidate to test this mode. I'm less happy to see that you finally decided to create a gridded project instead and archived . Don't you think it was worth giving it a try?

It would be possible to add a buffer to the arbitrary polygons when showing the task area in the editor (JOSM or iD) and I think it would make sense. I don't think it has to be optional. The buffer size could be determined programmaticaly.

pgiraud commented 9 years ago

Adding a buffer should be optional. Or maybe the buffer size.

FredM74 commented 9 years ago

For Gaza Activation I have done it during my holidays in a very short time. Mid October in Haiti, I will test it in a smaller activation, during a mapping party.

It is an important feature as we are making bloc /polygon (base on road, river, other) to digitize, send people in the field. For example in Haiti : During a census in urban area, we distributed the teams by block of 200 houses and we took OSM road to make or field paper map. Bloc/polygon (physical limit) are important for field survey and if we can assign a task (from the tasking manager) to each cartographer, then to the surveyors it will be much more easier to set up a good workflow. PS: In urban area we are taking river, road, tracks, etc..)

I will let you know in October

althio commented 9 years ago

@FredM74 It is nice to see the arbitrary tiling based on OSM roads. Impressive.

The data layer could have a bit of positive buffer as in #290.

@AndrewBuck

the polygons for the boundary were exactly along the road centerlines, they were not visible below the main data layer. When I switched to the 605.osm layer though I did see the polygon from the task manager. It might be desireable to be able to "negative buffer" in the polygons, (i.e. negative buffer distance so they shrink in about 10 meters or so) so that they don't fall exactly on the road centerlines.

Of course the situation is now slightly different because instead of .osm boundary you have .gpx boundary available for download and load into JOSM #390. Better still if you could import automatically the boundary of the polygon #498. If this imported boundary could be configured to be:

... I think it would be enough. The arbitrary polygon could stay untouched, no optional buffer on them, but rather keep the mapping boundaries accurate.

Unfortunately I didn't find any hints on selecting color and width while automatically importing a .gpx into JOSM.

pyrog commented 9 years ago

@althio

Better still if you could import automatically the boundary of the polygon #498. If this imported boundary could be configured to be:

  • above the data layer,
  • possibly with a distinctive color
  • and a significant width.
  • [x] above the data layer,
    yes, with the remote control, load in JOSM layers in this order :wink:
    1. imagery
    2. data layer
    3. Boundary
  • [ ] distinctive color and a significant width
    Yes, it's a "style sheet" in leaflet. See: http://leafletjs.com/examples/geojson.html