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. osm2pgsql, 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 _______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/dev
