Talk:Osmosis
From OpenStreetMap
Locale depending decimals
On my xp box with Slovenian locale osmosis made an extract from planet's node with decimal points:
<node id="6968827" timestamp="2007-11-06T20:56:47Z" lat="46.0544422" lon="14.5046166" />
into a node with decimal commas:
<node id="6968827" timestamp="2007-11-06T20:56:47Z" lat="46,0544422" lon="14,5046166" />
Trying to import such extract into mysql (with osmosis) it gave me:
Exception in thread "Thread-1-read-xml" java.lang.NumberFormatException: For input string: "46,0544422"
at sun.misc.FloatingDecimal.readJavaFormatString(Unknown Source)
at java.lang.Double.parseDouble(Unknown Source)
at com.bretth.osmosis.core.xml.v0_5.impl.NodeElementProcessor.begin(NodeElementProcessor.java:62)
at com.bretth.osmosis.core.xml.v0_5.impl.OsmHandler.startElement(OsmHandler.java:91)
at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.startElement(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanStartElement(Unknown Source)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(Unknown Source)
...
IMO OSM xml should always (regardless of current locale) be formatted with decimal dots (us locale), so that they are portable.
Temporary workaround is to include commandline parameters
-Duser.country=US -Duser.language=en
but permanent one something in the line of
Locale.setDefault(new Locale("en","US"));
during osmosis initialization.
- --Stefanb 07:21, 18 November 2007 (UTC)
- Fixed by User:Brett in version 0.24. Tnx! --Stefanb 06:57, 19 November 2007 (UTC)
Losless version of enableDateParsing
enableDateParsing option looses timestamps, however it could treat timestamps as strings, copy them to output as string values without really parsing them into a java Date object. This should still be quite fast AND lossless. --Stefanb 21:09, 4 December 2007 (UTC)
- Of course this would only make sense if no comparing of timestamps is needed. Or it could be implemented as lazy date parsing (handling them as strings until comparing is needed) --Stefanb 13:13, 15 January 2008 (UTC)
- Yes, I was thinking lazy parsing would be the way to go, and if they're unused in the pipeline, just write out the original timestamp string. Probably would have to change the constructor to accept a string instead of a date, and add another function to get the raw date string. --SiliconFiend 04:36, 16 January 2008 (UTC)
Producing empty timestamps
If the elements of input file don't have the optional(!) timestamp attribute (eg from Srtm2Osm) the resulting elements will have a non-sense (and probably invalid) timestamp="" attribute on the output. Not a major problem, but worth knowing and fixing sometime. --Stefanb 10:49, 17 January 2008 (UTC)
