[OSM-dev] Final kinks in osmosis planet dumping
brett at bretth.com
Mon Sep 10 11:32:23 BST 2007
Frederik Ramm wrote:
> So difficult to add a fixed "header" on output? I certainly can live
> without <bound>; it is used for JOSM etc. to show the downloaded area
> (which is *not* identical to the min and max lat/lon in the file!) but
> nobody will ever load the planet in JOSM...
It's easy to add a fixed header but the problem is that the task that
writes the xml file is the generic --write-xml task. It is not limited
to planet generation and used any time you need to write data to an xml
destination. It's not impossible to resolve but would require an
additional "bound" data type being supported by the pipeline which would
be modified by each task in the pipeline as required (eg. a bounding box
task would resize the bound box, a polygon may have to modify the box to
surround the extremities of the polygon) but it's not a 5 minute task.
A simpler somewhat hacky solution might be to add an optional argument
to the --write-xml task to allow the user to specify what is written ...
> I don't see a reason why we should not upgrade dev to 1.6; then again
> the casual user would surely be happy to have a 1.5 compatible
> version without the polygon task. I guess there's no magic way to
> simply disable the polygon stuff when the user running osmosis has
> only 1.5?
Not that I can think of. I can always maintain a separate 1.5
compatible branch without polygon support if there's enough demand for
it but was hoping to avoid that.
Alternatively I can modify the polygon task to use the jdk 1.5
GeneralPath class which I think uses float data types instead of the
Path2D.Double class which unsurprisingly uses double data types.
Perhaps this is a better solution. Again, I was just hoping to avoid
the hassle and possible data accuracy issues. In a year's time when we
have free java/IcedTea implementations this should be much easier :-)
Is float accuracy sufficient for a polygon extraction task?
More information about the dev