[Merkaartor] Templatized tagging committed

Fri Nov 7 11:32:26 GMT 2008

This is going to be a long mail. Sorry for that.

Recently there has been a disagreement on the implementation of tagging
presets between JOSM and Merkaartor. That is unfortunate, since having
a standard approach in this is clearly worthwhile for the OSM project.
While everyone agrees that tagging should not be strictly enforced,
almost everyone also agrees that having some common guidelines 
and automatism built-in in the editors is a good thing.

The value in having all editors share a common description of these
guidelines is twofold : less work when things change and a more standard
tagging across OSM for the majority of map features.

Now the focus of this mail is trying to find a description of those
guidelines that can be reused by as many projects as possible (at least
for JOSM and Merkaartor)

JOSM has a long tradition in this, it's presets file format has been
embraced by others in the OSM community so I would like to start from
there. The idea is to take the new ideas that Chris has implemented for
the Merkaartor format and see how we can bring them in the fold of the
JOSM presets file and use that one as a common standard.

On Tue, Nov 04, 2008 at 07:05:23PM +0100, Dirk Stöcker wrote:
> Changes of the general structure must follow some guidelines:
> a) Do not invalidate the work done so far. This especially includes 
> translations.
> b) Allow a smooth transition. JOSM needs to support the current format. I 
> will not accept changes, which are incompatible. New tags are fine. 
> Obsolete tags are fine. But new meaning to old stuff is not.
> c) Structure should be easily understandable without documentation. Don't 
> overcomplicate stuff.
> d) Changes should be better than current form, not only different.

OK, here is a list of additions that I would propose for the JOSM
format. I am not sure if they fit your criteria 100%.

The main problem with the JOSM file is that it is more of a user
interface description language than a tagging guidelines language.
And that user interface description might be well suited for a desktop
editor where the editing happens in a seperate dialog. But when that
user interface need to appear in a dockwindow or on a small form factor
screen as with Merkaartor, there is not enough context to differentiate
and present an acceptable user experience.

Here are my suggestions to additions/changes in the JOSM presets format.
What I want to know about each
- do you think this is a good idea. if no why.
- is there already is a mechanism in the JOSM presets file that solves
this that I didn't know about.
- if not, do you think it could be implementeable in JOSM.
- and what kind of impact would this change have on other projects using
this preset format.

a.
	<label text="Edit a Motorway" />
	<label text=" " />
	...
	<label text="Optional Attributes:" />
	<label text=" " />

This kind of constructs are used all over the place to create the appearance
of a header describing what is going to follow. It would be better if that
was made explicit by something like

This way an editor can be smart : maybe instead of having a whitespace
between attributes it can use a fine line. Or on a small screen it could
drop things after the <optionals>. A MAPlint type of application could
warn for missing tags described in the first part but not for missing
optionals etc.
This is I think a no brainer and very easy to implement in JOSM :
just replace both new tags internally to adding text label and a white
space label like in the original.

b. A lot of tagging guidelines might only make sense when another tag has
been set. The current JOSM format has limited support for this :
group/item constructs a 1 level deep hierarchy of possibilities. 
This breaks down with more complex constraints, like for example places
of worship. A combobox with denominations makes only sense for certain
religions and each religion for which it makes sense has it own list of
denominations. Ideally we would have a way to only present logical
choices based on what is already known about the feature.

The current JOSM presets punts on this and just includes all denominations
for all religions in the place of worship item.

I propose the addition of a new optional construct inside each item
	<selector type="expr/> 
This would only present the item when expr evaluates to true.
Then we could have this in the presets file under buildings (simplified)

	<item name="Place of worship">
	<combo key="religion" (list all religions).../>
	</item>

	<item name="Christian church">
	<selector type="[religion] is christian"/>
	<combo key="religion" (list all religions).../>
	<combo key="denomination" ... (only christian denoms) />
	</item>

	<item name="Muslim mosque">
	<selector type="[religion] is muslim"/>
	<combo key="religion" (list all religions).../>
	<combo key="denomination" ... (only Islamic denoms) />
	</item>

How would this work in practice? For example the user highlights an
untagged node representing the place of worship. Only the first
choice is presented to the user since the two others have selectors
that only match for mapfeatures that already have a distinct religion tag.

The user is presented with just a single combobox from which she
selects christian. The tag is added and the software re-evaluates the
options available. Now the first two match. We ambiguate by taking
the last one (preset authors should take care to have the most specific
options near the end of the file). The user interface changes and
now shows two comboboxes to the user: one for religion and one for
denomination which only lists the christian ones.

Vice versa if a user changes the religion from christian to muslim,
the software re-evaluates : the first and last item match. And it
changes the user interface to show the last match -> the one with
the islamic denominations combobox.

This principle is actually implemented by Chris in Merkaartor and I was
pleasantly surprised how well it works in practice. I understand it
would be a little more work to implement this in JOSM, but on the
other hand if it is not implemented at all, it would just ignore the
selector and present the user with a few more items in the group.

c. There is a lot of repetition in the JOSM format. For example things
like the layer combobox are repeated a lot. It would be nice if these
could be defined only once and then just referred to in the items.
An example could be
	<taglist id="roadlevel">
	<description text="Road elevation"/>
	<combo key="layer" .../>
	<check key="bridge" .../>
	<check key="tunnel" .../>
	</taglist>
	...
	<item name="Trunk">
	<include ref="roadlevel"/>
	...
	</item>

Sure, this makes maintaining the presets file a little easier but that is
only a minor convinience. The big advantage is to allow 
the preset author to express which tags belong together. For example
again on a mobile screen, we can now group these inside a collapseable
widget that only takes up space when the user is actually interested
in thos or with the N810 we could present each taglist as a seperate
tab in a dialog box etc...

Unlike the previous proposal, this change however will not be possible to
ignore if it gets used.

d. Auto tags is something that seems not be supported by the JOSM format. 
For example in some bilangual regions
the convention is that the name tag consists of the name:lang1 - name:lang2
For mappers in those areas this is a big time waster that the editor can
easily automate.  Supporting it could be as simple as
allowing a computed tag value like :

	<key key="name" value="$[name:fr] - $[name:nl]"/>

We could also use a different XML tag. The advantage is that tools not
supporting this construct will not get confused.

	<autokey key="name" value="$[name:fr] - $[name:nl]"/>

Please no discussion on if we want to have name tags that are constructed
this way. In some areas (Brussels for instance I know from personal 
experience), bilangual naming is very strictly enforced where the official 
name really is the concatenation of the French and Dutch name. 

If you can't appreciate a government
prohibiting a public service provider naming its shops 'Bootik' because
that name is closer to the word 'Boetiek' than to the word 'Boutique', 
then you haven't really experienced a bilangual society. :)

Please discuss!

cu bart