This is great, thanks Steve! I've got just a few comments mostly having to do with in-mapnik vs. not-in-mapnik scope. Going down the list,
1) layer tag: I usually solve this issue in pgsql queries, which I've been happy with. I think that the layer tag should influence the order in which geometries are fed to mapnik, and that mapnik should continue to be agnostic as to the source of the data it's seeing. 2) underlying roads and brudges: yes yes yes. 3) iterative label placement: also yes 4) point-in-polygon: heavens yes, also repeating labels for very large polygons with spacing awareness 5) icon rotation: yes please 6) svg icons: oh yes 7) variable width: not sure I understand this one 8) vignettes: yessir 9) spread text labels: isn't this in already? 10) different casing: yes 11) text labels to the side: yes yes 12) nudge icon: different from dx/dy? 13) mountain ranges on hint line: this seems out of scope for mapnik, to me 14) collapse areas: more of a data question, isn't it? 15) text rotation: sure 16) point and line data: I don't think I understand this one 17) icon/text coupling: absolutely, yes 18) separate two lines by minimum distance: dangerous to include in mapnik 19) add natural earth data: sure, but is this a thing for mapnik to do? So generally speaking it's excellent stuff. I think I object to a few of them being in mapnik proper (1, 13, 14, 18, 19) mostly on the grounds of scope and division of labor. I've been saying for a long time that OSM is not necessarily suitable as a rendering data source (http://mike.teczno.com/notes/slides/nacis.html) and we would need to do a bunch of work to prepare the data for rendering at different scales. Issues around linear features like rivers or roads being represented as centerlines or shapes, how features behave in proximity to one another, etc. all should be handled in a scale-appropriate way at the data source. I think this is particularly important because mapnik is used to generate tiles, and it generally deals with very small areas that need to be knit together and still work, visually (Cloudmade's tiles are uniquely awful at this). Mapnik's choice the painter's algorithm is the critical choice here that makes it even remotely feasible to think about tiles for the whole planet. In short, I'm enthusiastic about most of Steve proposals! I think some of them are really more about OSM than they are about Mapnik, and my feelings about changes to the rendering library can be summed up as Keep Mapnik Painterly. -mike. On Sep 25, 2010, at 3:03 AM, Dane Springmeyer wrote: > Hi All, > > Steve's great slides which he presented to us yesterday in London to inspire > coding plans are now both available... > > on slideshare: > > http://www.slideshare.net/steve8/mapnik-code-sprint-what-id-like-to-do-with-mapnik > > and as a PDF (with notes) here: > > http://dbsgeo.com/mapnik/ms01/chilton_codesprint-what-I’d-like-to-do-with-mapnik.pdf > > Thanks Steve! > > Dane > > _______________________________________________ > Mapnik-users mailing list > Mapnik-users@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/mapnik-users > ---------------------------------------------------------------- michal migurski- m...@stamen.com 415.558.1610 _______________________________________________ Mapnik-users mailing list Mapnik-users@lists.berlios.de https://lists.berlios.de/mailman/listinfo/mapnik-users
