User:Ulamm/Mappers, evaluators and feedback

DE:Mappers, evaluators and feedback

Reliability of records

Professional producers of maps, commercial as well as governmental ones, have a coordinating team that takes care that all maps of the same series have the same standard.

In an opensource project this equal standard is impossible, even if all participants do their best.

Therefore, in OpenStreetMap, parameters that logically can take the values "yes" or "no" (Boolean type of data), pragmatically need three values, present, absent and not yet recorded. The latter one mostly is expressed by the missing of the tag. Important is that every mapper does not only note if the object or quality he has searched for is there, but also has to note if it is not there.

In a similar way, if a structural element may be situated on the right or left side of a road or on both sides of a road, it is wrong to note *=yes if it exists on both sides (as some guidelines still do, unfortunately). The value *=both has to be noted explicitely (and is no more work than noting *=yes). In this case, the value *=yes is only acceptable in the meaning of "exact localization not recorded".

This is no absolute ban of default values, but wherever there is a certain likelihood of both (or more specific) values, OSM is unreliable if "absent" is not tagged explicitely, "both" and similar not distinguished from "any".

It has to be admitted that this principle of tagging is no guaranty of perfection: It can unveil if a feature of a road has been recorded or not, but it can't unveil if all roads have been mapped or if there is a forgotten one in between. Nor does this principle prevent phantastical entries.

Feedback

In several discussions, this or that way of tagging is depreciated as "tagging for the renderer" or "tagging for the router".

We mustn't forget: As a proverb, the phrases "tagging for the renderer" and "tagging for the router" mean the abuse of tags with the desire

• to enforce presentations or regarding, which the evaluating programs have not been designed for.
• to hide features, the evaluating programs have been designed for.

Except of such abuse, "mapping for the renderer" and "mapping for the router" is the best, we can do.

All participants (in wikipedia's newspeak "users") of OpenStreetMap take part in big co-operative publishing project. The data, entered by thousands of mappers, do not provide any benefit, if they are not understood and used by renderers and routers. And the renderers and routers cannot serve their destination, unless they understand the records.

Like every complex system, the functionality of OpenStreetMap cannot be maintained and improved without feedback. All the mappers and the maintainers of renderers and routers mustn't wait for feedback. We must look for it and give it.

Looking for feedback means for mappers, "you have to watch, if the records you have added are understood by renderers and routers". And for the programmers it means, "please look, if your program evaluates all data you want to be regarded". That doesn't mean that we are not allowed to enter features that are not yet rendered and that perhaps at the moment nobody has an idea how to render them or how to use them for the scoring of a router. On the other hand, no mapper should add records without an idea, for what or whom they could be useful.

For the mappers, giving feedback means to contact the maintainers of a renderer or router, if it is blind for information you consider relevant. And for the programmers it means to look at the advisory pages of the wiki, and to demand or enter corrections.

Exacter mapping is no mistake

• Of course, exact mapping as well as rough mapping has to describe reality, correctly.
• Of course, every mapper has to decide how much time and effort to spend for the research and documentation of those features, he is interested in. This way, there is no mapping without a certain amount of selection and generalization.
• Of course, some information, unless the selection is misleading, is better than no information.
• But no mapper is allowed to limit the exactness of data to his personal limit of interest.
• Some mappers are only interested in simple routing or a rendering showing where there is a street and where is none. Other mappers are interested in a complete understanding of traffic infrastructure or the structures of settlement, agriculture, biotopes, waterbodies and ground relief. This way OSM can serve as a feedback for administrations and a database for political discussions.

The mappers' task is to record reality correctly and in a way that also shows their depths of mapping (see above). This includes features already evaluated as well as features not yet evaluated.

Principally, selection and generalization are the task of the evaluating programs and their maintainers. The better these programs work, the better is not only their usability for final users, but also the feedback for the mappers.

This leads back to an aspect of the chapter above: If your favourite renderer or your favourite router is puzzled by exact informations, do not delete these informations, but ask for the improvement of the evaluator.

And it implies a task of communication amoung the community: OSM's database is worldwide. Evaluating programs ought to be able to utilize and visualize data all over the world. This does not work if each mapper creates his own sandbox within the database. The community has to confirm standard tools to describe features unequivocally. Many of these tools are necessary internationally, even if in some regions there is no use for them. Of course, the necessity of standardization does not forbid, but sometimes even affords, experimental local use of new tags and other tools. (See "Any tags you like")