[OSM-dev] OSM Date Formats
brett at bretth.com
Tue Oct 2 05:00:37 BST 2007
Frederik Ramm wrote:
> To clarify: There is no proper JOSM mailing list yet, so use dev for
> the time being.
> There are currently four people with JOSM SVN access - Imi, Rob,
> Gabriel, and myself. Imi has somewhat unexpectedly handed JOSM over to
> me, and I haven't yet had the time to sort everything out. Imi used to
> have a rather tight grip on JOSM development, liberally rejecting or
> changing patches that were submitted to match his design goals, and
> while not perfectly "OSM style", on the whole JOSM has benefited from
> this kind of benevolent dictatorship (or "strict QA" as you may put
> it). I cannot be that same "benevolent dictator" because I lack Imi's
> overall vision, so I hope that we will manage to get more people
> involved in JOSM development without dropping that little "QA barrier"
> altogether. I'm open for suggestions on how to best do that, but I
> think it can wait until 0.5 is out the door.
I'm fine with this, so long as it isn't impossible to get changes
reviewed and added. A QA barrier is a good idea if the committers have
the time to deal with patches in a timely manner. It will discourage
potential contributors if patches are seen to be ignored.
I'd really like to see these changes made because JOSM is not supporting
standard xml date formats, but it can wait for 0.5. If all tools can
converge on the standard xml date formats then stricter schema
validation becomes possible.
As for the reviewing the patch, there are a few things worth considering:
* The existence of the custom date formatter is not strictly necessary.
It only exists to remove millisecond information which isn't a major
issue for JOSM sized files, it's only included for consistency with
osmosis (and hopefully planet.c in the near future). Using
XmlGregorianCalendar is the simple alternative.
* The existence of the custom date parser is not strictly necessary. It
exists for performance reasons only which are unlikely to be an issue
for JOSM sized files. The alternative is to remove the special case
custom parsing and go straight to the XmlGregorianCalendar parser.
* Exception handling isn't ideal. I'm throwing ParseException out of
the parser code to align with existing JOSM code but this may not be
ideal. The ParseException is supposed to include offset information
which is not being populated, although the old code didn't even include
an error message though so the new code should be an improvement.
* The patch includes a change to the OsmReader.readCommon method to make
it private instead of package access. It all compiles but I didn't take
into account any potential impact to plugins (I don't know how to verify
this). This change is not really part of the date changes and can be
dropped if there is an issue.
The date code I've added is almost identical to the code included in
osmosis. osmosis is capable of parsing a 16GB planet into full-blown
objects in less than 15 minutes which required a few tweaks and some
custom code to achieve. JOSM parse time isn't as critical. At some
point it may be possible to factor out common code between various java
applications into a common library but I don't want to attempt that task
I'll shut up now :-)
More information about the dev