[OSM-dev] Verify upload of trackpoints/segments

bvh bvh-osm at irule.be
Sun Oct 22 14:31:15 BST 2006


On Sun, Oct 22, 2006 at 12:27:58AM +0200, Joerg Ostertag (OSM Munich/Germany) wrote:
> Well for the routing application you can take car=no as a default, but for 
> other users this would be miss leading. I would assume you already checked 
> the tagging concerning car=??? and decided it is no. So this would lead me to 
> a false conclusion. It tells others that you already know that you cannot 
> drive along this segment with a car; which is wrong.

Which other users? What use case would be problematic for this particular
tag? Honestly I think a use where you absolutly must know if a road is
car free is rather farfetched and probably some ways of for openstreetmap
project due to other needs.

My main concern is making map editing easier. This may take a while
to explain, so please read on.

While the tagging system is
excellent from a technical point of view and works well in providing a
flexible datastructure, it is just not nice to actually use.

When I first tried JOSM, as an absolute beginner, the tagging was an
extra hurdle. You don't want a beginner to have to lookup a wiki page
to find out that she/he must add a "oneway" tag with value=-1 to get
the desired effect. What he/she wants is a simple checkbox
[X] One way street  and a push button [Change trafic direction] 

I think for Openstreetmap to be succesfull the editors must go down to
that simplicity so that anyone can participate, not just the motivated.

Now, under the hood I agree we must keep the loosely structured tagging
system. It is the only way to be flexible enough to adapt to the
bewildering number of rules and features that are out there. So the
client software must provide an interface between the tags and a
simple user experience. I believe the only problem in there is that
tags like width, oneway, car etc... that normally are easily represented
by just a checkbox, number edit or combobox all of the sudden also
have an extra non-obvious state unknown.

cu bart




More information about the dev mailing list