Waldemar, I like the idea of you collaborating as the two projects are very closely related - one is the 'user' front end, while the other is the processing part.
You do need to be careful that you are both working on different projects, but collaborating, rather than working on a larger joint one: The GSoC FAQ says: 1. Can a group apply for and work on a single proposal? No, only an individual may work on a given project. Of course, students should feel free to collaborate with others to accomplish their project goals. My recommendation would be for you to get on with your Danjo front end to allow the user to select different style sheets (or edit the stylesheet) to do different mapnik rendering, add POIs etc. so that you get something working fast. Carlos can work on the better quality output for mapnik, and as long as you know what his new options are going to look like, you can bear these in mind when you produce your code. If you find that you can not improve the output further without improvements to Mapnik (as you state in your proposal), then you could help with the mapnik bit at the end. My concern is the mid term evaluations (that you need to pass to get paid!). I can't remember what the questions are, but I think it is about progress towards your project goals - if you concentrate on mapnik first it will be difficult to argue progress towards your goals? Anyway, those are my suggestions, but you may want to read the GSoC FAQ yourself to check if I am wrong! I hope this helps! Regards Graham. 2010/3/29 waldemar quevedo <[email protected]> > Very interesting discussion indeed, thanks Carlos for your thourough > research. We were just discussing this late yesterday and already sent and > email this morning, thanks for that! > I have taken into consideration what was discussed and I think that if > we're both accepted we should tackle first mapnik's rendering options, > resolution and scale issues so that we do not become too dependent at the > end of the projects. > Maybe one way of decoupling the projects (specially mine, the web front end > project since mapnik is a huge dependency) would be to make a third schedule > for the proposal, one where we both specify the way we are going are going > to collaborate. This way we would both work on having a solid proposal for > each project without depending too much on the other project. If one of us > is not chosen then we would carry on and work on the original schedule, and > if we're both selected we would work on the 3rd schedule (which would only > be sent to the maling list and mapnik/osm community not to Google). What do > you think? > > Here is a draft of my current proposal for the OSM project, please tell me > your thoughts, I will update it later today: > http://wiki.openstreetmap.org/wiki/Google_Summer_of_Code/2010/Student_Applications#Draft_application:_Better_Print_Support:_OpenPaperMaps.3F > > I would also like to point out Carlos and I go to the same school, have > some classes together and have been meeting all week to work on this > project. If we're both accepted we would have a similar working flow so that > we're both at the same page. > > Thank you all for your suggestions and good luck at the Where2.0 > conference! > > - Waldemar > > 2010/3/29 Carlos Enrique López Garcés <[email protected]> > >> Good evening. >> >> I just wanted to share the way I understand the project, so here's an >> email I sent to Mr. Springmeyer. I'd appreciate any feedback you could give >> me: >> >> Good evening Mr. Springmeyer, how are you? >> >> I'm sending you this email to see if you could answer me some questions I >> have about the 'Better Print Support' and to let you know about the picture >> I have of it. Since you are visiting Mike Migurski and Tom Carden tomorrow, >> it would be great if you could also share this email with them to make sure >> that these ideas and questions make sense. >> >> Talking to Waldemar and reading some resources in the OpenStreetMap wiki, >> I found out that a major need this project has is the capability to >> customize the way a map is printed in digital file formats, such as PDF, >> Illustrator's and Inkcape's, so it can later be printed to paper of various >> sizes. People find it hard to print a map correctly because difficult extra >> steps are necessary, which require the knowledge of other tools, and the >> results are sometimes inaccurate. To mention examples of the former issue, >> Nicolas Marichal says that lacking the capability of turning on/off specific >> layers the resulting map files tend to be too large to be handled properly >> (Waldemar showed me a PDF file generated with MapOSMatic that was really >> large and that caused his PDF viewer to crash (I hope this is what Nicolas >> Marichal was talking about)), containing unnecessary elements the user may >> not want to see in her map. About the latter issue, he mentions that some >> elements are sometimes displayed in wrong positions ("water areas sometimes >> appear wrong, as if the city is flooded"); I guess this is the result of >> resizing or scaling the map. >> >> To overcome these problems, you suggest that OSM's "Easy Printable Maps" >> project should be based upon the work done in the "Better Print Support" >> project, which will address some of the issues mentioned above. The >> existence of tickets #343, #320, #389 and #358 is a sign that the intention >> of improving Mapnik in these areas has existed for quite a long time now. >> Reading the description of these tickets, I realize that they are indeed >> related to what Graham Jones identifies as the main concerns of these two >> projects, namely 'resolution', 'rendering options' and 'scale'. I'll comment >> on these tickets next (please, tell me if any of the ideas I've mentioned so >> far are wrong): >> >> Ticket #343 (Add a resolution parameter to Map object): The goal here >> would be to be possible for the user to specify the resolution at which the >> map should be printed in the digital file (pdf, ai, inkscape, etc.), >> expressed as a scaling factor that would manipulate the size of symbols, >> fonts, lines, etc. The scaling should be done in such a way that the spatial >> relationships between elements is preserved (to prevent lakes from moving, >> for example). My question here would be if the capability of specifying a >> custom resolution parameter is what you refer to as 'multi-resolution'. >> >> Ticket #389 (Add optional but explicit units everywhere): As I understand, >> Mapnik currently uses PPIs as the unit for specifying the resolution of the >> map, but it is desirable that other measurement units, like mm, cm and >> microns, be used as well (I'm not completely sure about this, though). As >> the title of this ticket states, it should be possible to specify everything >> that's measurable inside the map using various units (Robert Coup mentions >> in his reply to my latest message in the mailing list that longitude and >> latitude lines should also be displayed using units other than degrees, like >> meters). Finally, the default unit should be pixels. >> >> Ticket #320 (SVG-Based Symbolizers): I don't have enough information to >> comment here, but Mr. Pavlenko said he is interested in an SVG renderer. >> >> Ticket #358 (Implementation of map borders and coordinate grids similar to >> those provided by GMT): The features discussed in this ticket are those that >> Robert Coup suggested (in his reply to my message in the mailing list) and >> that are already implemented in the experimental-pdf branch, but using >> WXPDFDOC. The idea here is to provide these features with a Cairo-based >> renderer. >> >> My questions for Mr. Migurski and Mr. Carden would be: >> >> #1 I don't fully understand what they mean with "use the same renderer for >> web cartography as multi-resolution cartography". I interpret the sentence >> as providing support for producing maps with different resolutions within >> the same renderer (Cairo-based preferably). >> >> #2 Does my vision of the project agree with theirs? >> >> I'll post the contents of this email in the mailing list too. Maybe other >> members might want to add their comments. >> >> Thanks in advance. >> >> Carlos Enrique López Garcés >> >> >> _______________________________________________ >> Mapnik-users mailing list >> [email protected] >> https://lists.berlios.de/mailman/listinfo/mapnik-users >> >> > > _______________________________________________ > Mapnik-users mailing list > [email protected] > https://lists.berlios.de/mailman/listinfo/mapnik-users > > -- Dr. Graham Jones Hartlepool, UK email: [email protected]
_______________________________________________ Mapnik-users mailing list [email protected] https://lists.berlios.de/mailman/listinfo/mapnik-users
