[OSM-dev] OSM Date Formats

Brett Henderson 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 mailing list