[OSM-dev] GSoC Project Update / Wishlist / Thoughts.

Samir Faci (Dev) dev at esamir.com
Wed Jun 15 19:03:38 BST 2011

The GSoC Project thread sort of spawned off this email which somewhat
diverted away from a related response.

Just my own comments, based on my own experiences, I might very well
be doing something silly
where I just haven't seen the light/proper way of doing things.

I was wondering if any of these issues are addressed in someway that
I'm not aware of, or there
is a strong reasoning to why things are done the way they are.

One thing I really wish existed is a tagging system for the variety of
tools developed by OSM.

modtile, etc... as far as I can tell the svn repo has no
branches/tags.  I would love to have the
ability to say... oh the latest stable to release of modtile is ver X,
let me check it out, build it and deploy it.

I know that there are git mirrors for these projects, but I think git
is a second class citizen, and I haven't noticed
any tags in git or svn.

dependency mapping is a bit difficult to determine.  Latest version of
trunk depends on mapnick tools 0.7.1, but
determining which revision.  I think I had issues at some point
because the stylesheet that osm2pgsql wasn't updated
so the planetosm import expressed odd behavior.

the world_boundaries is another unknown beast.  I'm never sure when I
need to update these, or when not updating these would break
the rendering process, or render improperly.

a mapping between planet.osm to a state.NNN file.  I think most people
that use diffs, tend to load the planet.osm file in slim
mode then generate a changes.osc file based on a state.txt file, but
as far as I can tell there is no exact mapping.  I tend to overshoot
the date of the planet.osm file by 24hrs just to be safe.  It would be
nice if we could say I downloaded planet-110608.osm.bz2 and the
state.txt file associated with it is planet-110608_state.txt.

Samir F
PS.  Any reason why  osm2pgsql

More information about the dev mailing list