[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.
PS. Any reason why osm2pgsql
More information about the dev