On Tue, 4 Nov 2008, Chris Browet wrote:
> Why not.
Because a lot of work is wasted for duplicate efforts rather than new
developments?
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?
http://josm.openstreetmap.de/wiki/TaggingPresets
http://josm.openstreetmap.de/svn/trunk/presets/presets.xml
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
conflict.
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.
Ciao
--
http://www.dstoecker.eu/ (PGP key available)
_______________________________________________
Merkaartor mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/merkaartor
