[Merkaartor] Templatized tagging committed
openstreetmap at dstoecker.de
Tue Nov 4 12:38:51 GMT 2008
On Tue, 4 Nov 2008, Chris Browet wrote:
> > Why not.
> Because a lot of work is wasted for duplicate efforts rather than new
> Unfortunately, in my experience (see the numerical vs. textual id tag
> thread), much energy is also wasted in trying to make the 2 projects
> collaborate (the "JOSM standard" syndrome ;-) )
You still could no prove your point here and I agree with Frederik that
changing a widely established format (we do not talk of JOSM only here)
without a real good reason is no option.
You finished the discussion, when the question was very clear: What is the
advantage of your improvment, whereas the disadvantages have been clear.
Anyway this is the wrong place to continue that discussion.
> > Key features for me:
> You did not say where your requirements conflict with JOSM.
> Because I don't know what capability the "presets.xml" format have. Is there a doc somewhere?
> Speaking of wasted efforts, trying to bend an existing format to my
> requirements seemed much more wasted time than creating my own.
We have 1385 lines of strings to translate in the JOSM presets format. If
you multiple that with e.g. 6 for the languages, then the work to create
and support a file format definition is much outweighted by the work of
the people lateron supporting that format. Sorry. Not always is the
programmers side the best view.
> To whom would a common format benefit anyway (besides the translators,
> and again translated tags is not one of my own requirements)?
Yes and I still consider it a bad habit of you to ignore the requirements
of so many only because it does not fit your own opinion. Nevertheless
this is again the wrong place to discuss this.
> My original idea is to allow users to create their own templates based
> upon their own (local) requirements. A centralized, svn-based, common
> template contradicts this idea. It can be mitigated with, e.g., a wiki
> page with a repository of templates, but does JOSM support changing
> templates on-the-fly or in preferences?
We are not discussing the way how the file is used, but how the fileformat
looks like. That is a big difference.
And yes, JOSM supports loading of multiple preset files including local
modified variants as well as weblinks. Thought there are only few examples
of alternative preset files and usually they are outdated since a long
time, whereas the internal file is updated regularily.
> Obviously, using JOSM format is not a requirement for me. For easyness
> of the translators using both editor (i.e. you AFAIK), I could use it,
> only if I don't loose functionality.
About half a year ago I already agreed to support sensible changes in the
file format to allow integration into different editors. I never got a
response to this, but now I see a totally new fileformat. It is pretty
clear, that you do not like to support previously established standards,
but rather start your own invention. This is nothing I consider useful.
> > - Ability to use some lexical parser to automatically display the proper
> > template for a given feature (i.e. my "<selector>" tag), in addition
> > to the simpler "<key>" tag, which, I assume, do the same (only that I
> > don't have to repeat the template for every single value of
> > "highway"). I also allows me to display different templates based
> > upon the type of the feature (road, relation, trackpoint, area)
> JOSM template format already has a definition for road,relation,..., but
> it is not used by JOSM and thus the files are not complete here. This is no
> Great. Why is there a dozen identical templates for the "higway" tag
> again, then? Plus, my format supports references to <widget>, thus, for
> instance, the "landuse" tag can be defined once and referenced in
> templates with <widgetref> -> Maintenability enhanced.
Supporting of this type of "define" is a good idea and I would also
support this for JOSM to reduce duplicates in the XML file.
> Long story: Brussels is a bilingual city in a trilingual country (like
> others, I suppose). The standard tagging for streets is to indicate the
> name in french ("name:fr"), the name in dutch ("name:nl") and both in
> the "name" tag, i.e. "name:fr - name:nl". It's a great timesaver to just
> indicate the name:* and have the "name" automatically generated.
Actually that is nothing which should be supported at all.
This is something, which in future has to be fixed by map applications
showing the name dynamically based on the users language. The current
crude workarounds do not need additional support from the applications.
http://www.dstoecker.eu/ (PGP key available)
More information about the Merkaartor