[OSM-talk] Recording completeness
Robert (Jamie) Munro
rjmunro at arjam.net
Mon Jul 16 22:29:03 BST 2007
-----BEGIN PGP SIGNED MESSAGE-----
Chris Morley wrote:
> At SOTM07 it was apparent that there are many organizations ready to use
> OSM data when it is complete enough. The need for measures of "quality"
> was also raised. So perhaps now is the time to set up a framework where
> "completeness" can be recorded. It would provide not only a measure of
> progress, but also be an incentive to mappers to literally go the extra
> mile. As has been previously noted, well-defined "complete" areas (IOM,
> IOW) are a valuable publicity tool.
> There are many possible ways of recording completeness and there have
> been intermittent discussion of this in the past. (Being aware of all
> previous discussion on a list like this is not easy.) But here is one
> possiblity, for discussion.
> Completeness boundaries would be ways in the the main data base so that
> contributors can push the boundaries on a day to day basis. A boundary
> of completeness would always be a closed area with the completed area to
> the right of segment direction (like coastlines). This means that the
> meaning of a boundary would be understandable even when only a small
> part of it was visible. It would also mean that the areas couldn't be
> tiled (segment directions wrong) but that it would be easy to merge
> them, which is what is really needed.
> Obviously, there are various levels of completeness, and it would be
> necessary to tag the boundary with a description of this, for example
> boundary="complete" completeness="public roads". It would be better to
> use standard text descriptions like "major roads" or "public roads" for
> this, rather than a numerical index. Areas of different completeness
> could be nested and could share nodes/segments in part. There would be
> guidelines on what the various categories meant. So maybe "public roads"
> could mean that >97% of public roads in an area had ways and were named
> where appropriate, with enough information for basic routing for cars -
> oneway, etc. I think this is the category that should receive the most
> I'm not clear whether each area would need to be a single way (necessary
> for local rendering?) or whether they could be conveniently split, like
> coastlines, and viewed via a low zoom custom rendering in
They would have to be able to be split like coastlines - they could
easily get very long. Also, like coastlines, they could have holes in,
like lakes with islands.
Another possibility is to tag roads that are in the database as
complete, meaning that the road itself is in full, and every turning
from it is marked, (even if those roads are not complete themselves).
Robert (Jamie) Munro
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the talk