[HOT] [RFC] suggestions for HOT work
david at black.co.at
Sat Sep 1 21:29:17 BST 2012
On 2012-09-01 07:25, Pierre GIRAUD wrote:
>>> 3. A multi-stage completion process could be useful. For example, if
>>> the most important thing is to map the main roads and residential
>>> areas, these could be completed and the square marked as 'level1
>>> complete' and you could move on to another area.
>> On a similar tangent, it would be really great to have a global TM with
>> finishing levels which keeps track of up-to-date-ness, complete-ness and
>> data fidelity.
> Can you please elaborate?
A first draft of my ideas can be read at the bottom of
One of the building blocks would be global knowledge about who traced
what from which source. TM does this for a given area: it records when a
volunteer has updated OSM to match the one source.
My basic motivation comes from the experiences in Austria, where several
high quality data sources exist:
* complete coverage with 15-20cm/px aerial imagery
* partial coverage with laser scan data
* partial coverage with state-funded open government GIS data (e.g.
buildings, roads, names and housenumbers as WMS in the capital, Vienna)
Additionally, of course, several very conscientious users keep their
respective areas up-to-date above and beyond what can be gleaned from
the available WMS sources.
Still, the community is struggling with cleaning up a botched
(misclassified highways and tracks, offsets up to 100m, etc, etc) import
which is already several years old and there is no telling which parts
of the map are really clean and which only look almost OK.
And every year the data sources update without much notice, letting OSM
slide behind farther.
While remapping against the redaction, I noticed that using the right
data-sources and not stepping on changes done by locals is very hard,
because the provenience of the data is hidden in out-of-date source=*
annotations, possibly on the changeset instead of the way, or has to be
inferred from the relation of last-date-of-change and the (often hidden)
timestamp on the source data.
My vision in this problem space has three parts:
1) Provide an inventory of source materials for OSM data. (WMS,
imports, walking papers, maaping parties, etc)
2) Provide a record of data-fidelity/currentness for OSM data.
3) Organize volunteers around sources and areas to translate sources
into up-to-date OSM.
The TM addresses these points, albeit severely limited:
* it provides only a single source (1)
* it provides the data source catalog only to itself (1)
* the record of fidelity is local, not exported (2)
* its job scope is local, not global (3)
* users have to actively use the TM in addition to their other tools
In the context of the Geo-Data-Pipeline referenced above, both a
stronger separation of concerns (data catalog, and data-fidelity
recording as separate services) and a stronger integration (checkout
tasks directly from editor, automatically configure sources for current
viewport) would be required. Like the TM today is already used beyond
HOT projects (e.g. http://rebuild.poole.ch/) and has become an important
tool, I believe that there exists a huge overlap for other services
between HOT's use cases and the global requirements for an improved OSM.
One of the most interesting artifacts in this facet would be #2: a
catalog which could answer for each area how current the available
source-data is, how current the available OSM data is and to which
degree of detail the data is available:
Even in Vienna, my hometown, there are areas where no building data is
traced, and there are areas where building data is traced from aerials
which were quite horribly distorted and already replaced by the city's
GIS WMS which has proper ground plots instead. Still, almost nobody
seems to be updating them. Even finding those areas (and keeping track
of them) is annoying to say the least.
I hope this can give you a glimpse into my vision. Feel free to chat me
up on G+ or Skype (davidschmitt.at)!
>>> 4a. I don't know if it would be possible to set up the task with
>>> different sized grids in urban areas. Say for example a 1km grid over
>>> the wider area, but with each 1km square split into 4, 9, or 16
>>> smaller squares in dense areas?
>> Pierre, you're already working on that? Great! would it be possible for
>> mappers to dynamically split tasks? or will the admin have to do that?
>> Anyways, looking forward to that!
> This is already available on the current TM. There's a small button at
> the bottom of the task tab when you take one. Each user is allowed to
> split tasks. No admin user contribution is required here.
Need to update soon, then! :-)
Best Regards, David
More information about the HOT