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

Reply via email to