All Roads Lead to Packaging for Debian
Just a quick update to say that I have exhausted all my options to build a latest .osm file from fosm.org minute-replicate osc files + a base .osm file from osm.org. Currently fosm.org is down, but I still want to edit on top of the latest data so I can submit my changesets when it comes back online. This is proving to be more difficult that I thought. Although really it is a good thing as even though I’ve tried to ensure I have everything I need to rebuild fosm.org if it were to go down for good, I’m still not 100% sure as I haven’t tried, well now I get to try.
My first method was to use osmconvert with the aid of the workflow given in
. It was quite fast and it almost worked, but due to limitation of osmconvert it seems that it expects the objects to be sorted in the order given by the object IDs. We can either patch osmconvert to work around this, or sort the osc files…
Putting the first method on hold, I gave installing the rails port that runs the API at osm.org a go with the idea that I can load the changesets or osc files directly into the API or DB. I got it installed and got to the step of loading in my starting OSM .osm file from before the FOSM fork.
even gives the command line to run, but osmosis didn’t like this. I believe the issue is fixed with later versions of osmosis though.
This leads me to require a later version of osmosis. I don’t really want to install osmosis from source using the upstream project’s method as it will pull in a bunch of 3rd party libraries using maven, so the only real option is to work to upgrade the debian package for osmosis. This isn’t easy either as I don’t know that much about ant/maven/ivy. I could spend I whole weekend just trying to update the debian package of osmosis and still get nowhere, all the time I’m just getting further away from my original goal which was to make some FOSM changesets from my latest trip while my memory is still fresh…