[OSM-dev] using propper tools; building Packages; was:planetosm-to-db.pl
richard at systemeD.net
Wed Nov 8 09:42:45 GMT 2006
> Well the modules are neither King Size nor written by a bazillion King ;-)
> So the interesting question would be which platform did you try to run it and
> what can we do to make the installation of a complete OSM package much
> easier. I'm thinking of building a complete OSM package which would hold ALL
> necessary programs and base Data for working with OSM on a userclient. So one
> important thing would be to find people who know how to build packages for
> the different platforms.
The machine in question is a MacIntel laptop, Perl 5.8.6. Installs
most Perl packages pretty easily. I should say that the problem isn't
in installing the packages, it's in the necessity to do so (and the
difficulty of getting them without installing svn, especially when
> I don't see any problem with installing svn. Even more; if you try to do
> serious development you definitely should use a Program for version-control.
> For example if you want to make some local changes to any of the programs;
> you don't want to have to change this over and over again every time a small
> bug in the programs in the repository is fixed and you did a re-download.
> These are things which should even convince a 0815-user who is tweaking
> around a little bit inside the config files or programs.
> But If you really want to refuse to install svn you still can do a
> wget -r --mirror 'http:://svnopenstreetmap.org/'
> Sorry to sound harsh; but I really don't understand this kind of whining
> around about using proper tools. And SVN is a proper tool for handling
> Versioned Software.
I agree completely... but it's not really what I'm trying to do here.
My proper development machine at home has svn, Perl, Ruby, two
bazillion king modules, eighty hacked flavours of Ming and lots of
stuff I don't really understand.
But here, I'm trying to get some data - nothing else - onto my work
laptop. Not really "proper development", just getting the data so I
can play around with it using a quick-and-dirty Perl script, then do
something like transform it into an .ai/.eps and make maps out of it.
IMHO you shouldn't need a full suite of proper tools just to get the
> Well it doesn't have to be too hard. What about really building packages for
> the standard user to install the complete OSM suite?
>> b) the Geo::OSM stuff are submitted to CPAN, for ease of installation?
> I'd love to. There was already a start where people were thinking of
> building/packaging a complete Geo::* Module. I would be the first one to be
> happy to commit stuff to this Module as soon as someone tells me where to put
> it and how the existing interfaces for these modules are. I would even try to
> rewrite/rearrange/rename/... my modules to fit into a given Geo::scheme.
> These Modules are only a start to show that we don't have to write the same
> stuff over and over again.
Ok, I'm happy to help getting it CPAN-ready. Never done that before
(but hey, there's a chapter on preparing modules for CPAN in the Camel
Book, isn't there?) but, yes, surely having a Geo::OSM module in CPAN
could only increase takeup of OSM data.
Thanks for a constructive reply. :)
More information about the dev