On Mar 29, 2010, at 5:07 AM, Carlos Enrique López Garcés wrote:
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?
Great, thanks!
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.
You bet, nice thought!
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.
Exactly.
People find it hard to print a map correctly because difficult extra
steps are necessary,
Yes and no regarding extra steps.
Some users main goal is to enhance/customize Mapnik maps with the
target of post-processing the output. Other users may not be concerned
about any postprocessing, and rather just need customized maps at
higher resolution, or rotated, or with auto-generated scalebars.
which require the knowledge of other tools, and the results are
sometimes inaccurate.
Perhaps inaccurate, but more likely not aesthetically perfect or
otherwise hard to get the GIS data into a design application to be
edited further.
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)),
Interesting. I've not noticed this problem before of the PDF output
being too big. It would be good to know more about which PDF viewer
Waldermar was using to try to investigate more why it crashed.
That does bring up another interesting idea - that perhaps we should
add the ability to smooth/simplify the vector output generated by the
cairo_renderer to allow for smaller file sizes. However, usually when
users want to print out maps they intend to print to large paper, and
so a bigger PDF is better. But certainly in some cases smaller output
could be desirable. I'm not sure that is within the realm of "better
print support" but it is an interesting idea nonetheless.
I think Nicolas was referring to a different problem for his use case.
I think he has primarily used the 'Export' function to generate a PDF
from this page:
http://www.openstreetmap.org/export/
In this case the PDF is generated from the default 'osm.xml' located at:
http://svn.openstreetmap.org/applications/rendering/mapnik/
I think there are two key problems here for users that want PDF output
to post-process, both of which could be solved nicely through a web
interface + some custom stylesheets.
1) That 'Export' interface on the openstreetmap/export page does not
have a web based mechanism to allow for turning on or off layers
(essentially setting the <Layer status="off">), which Mapnik supports.
So this could be supported by writing a web application to expose
options to the user to control which layers Mapnik renders.
2) The default 'osm.xml' style has some very sophisticated and complex
logic to display various OpenStreetMap features that targets nice
looking PNG output, not vector (PDF/SVG) output.
For example, because the "Painters Algorithm" is used in Mapnik
problems like nice looking "Road Casings" are solved by drawing
repeated features several times with different symbolizers. While this
looks good in PNG output (and likely just as nice to the eye in PDF/
SVG output), if the goal is post processing (vector output) this
approach leads to many overlapping lines that are very difficult to
later edit/select/change. Potentially in Inkscape or Illustrator a
user would be wanting just the raw road line or a few types of roads,
as single lines part of one layer, because the look of nice road
casings could be achieved through different methods in the design
application.
So, a large part of this problem could again be solved by a web-based
interface that allowed the user to choose between a few different
Mapnik XML styles that could be written (I could help with this as I'm
sure many other Mapnik users!) to produce more simple layers and
styling. Basically, new XML styles and layers could be created that
better match the exact types of OSM features the user might want to
post-process, and the web interface could allow some level of
customization that exposed the ability to combine or separate features
into different layers.
I must note that my ideas here will not solve all of the issues
Nicholas raises, but I think they would help a lot and are the easier
and more rewarding first steps. To solve all of the issues at once
that Nicholas raises one might be better off with a very different
approach, which is to use/extent the osm2ai script that is specially
designed around turning osm data into basic vectors for adobe
illustrator. A web interface built for this project could potentially
add that as an option too, but overall I see great value to furthering
Mapnik's support for better post-processable output because Mapnik
works with more than just OSM data and most of these ideas,
particularly those that could be solved through a web interface to
customize output, would also benefit users that seek PNG output too.
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.
Regarding wrong display, the "flooding" issue may be easily solved in
his case by updated osm coastline data, but perhaps it also has
resulted from bad conversion of polygons to svg/pdf vectors. This is
something that could use more investigation and would be a good ticket
at mapnik trac.
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.
Yes, as above. But certainly a web interface to make printing maps
easier (and better looking, or better for post-processing) could also
integrate a few other tools than Mapnik is beneficial.
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.
Yes, exactly, although they are actually not that old. I think they
are just now really gaining attention and need and thats when things
really start getting done :)
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):
Yes!
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'.
Yes. I think my term "multi-resolution" is a bit confusing. Maybe
variable-resolution is more appropriate, but either way you are
certainly understanding.
I created #343 and wrote the initial patch very quickly and I need to
look back to fix up and improve. I will do this this week. My thinking
now is that even if we do not have the proper ability to scale symbols
yet (#320), adding this functionality would still help immensely. The
main task here will be testing and fine-tuning to make sure that the
scaling is appropriate and flexible enough (I will comment more on the
ticket).
Also, for a concise discussion of this idea (in a different software
project), see also:
http://igorbrejc.net/openstreetmap/maperitive-bitmap-scaling
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).
We should take more with Mike Migurski about this. I think that my
comment on that ticket may be off topic.
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.
Yes, great description. Basically I think Mapnik should be able to
convert various units so that users that think better in units other
than pixels could more easily author stylesheets - this is
particularly relevant to Cascadenik. But the idea may go beyond this,
so we should check with Mike.
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.
Yes, this one is hard and my feeling is that it is not within the
scope of GSOC, but I'd be happy to be wrong. The main functionality
here is already implemented, but the Mapnik developers need to discuss
further about the approach. I think that Artem is interested in using
the more basic support inside AGG for reading/rendering SVG instead/in
addition to RSVG, but we should hear more from him.
Also, I think his idea for an SVG renderer is different. #320 is about
being able to read/render SVG symbols and I think what an
'svg_renderer.cpp' would be about is writing a new output renderer
that would be very good at authoring SVG (better than Cairo). This
could be very very useful for Nicholas and others than desire optimal
SVG output for post-processing. I think Nicholas used the PDF output
in the past over SVG because Cairo's PDF output is slightly better
supported than SVG, though SVG may be more desirable/flexibly for post-
processing in general.
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.
Yes.
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).
Yes, you are understanding right. I actually added that line - sorry
it is not very clear! :) Mostly what I am getting at is that Mapnik
Core should be extended (as discusssed above) so that variable
resolution output is better supported both in the cairo_renderer
output (PDF/SVG) and in the agg_renderer (PNG).
#2 Does my vision of the project agree with theirs?
Yes, but we should hear from them as well soon.
I'll post the contents of this email in the mailing list too. Maybe
other members might want to add their comments.
Yes, please. I hope that others add comments as I am just thinking
through my experience of hearing from users and thinking about how to
better solve problems in Mapnik. Other users will have more clear
ideas on many subjects.
Thanks in advance.
Carlos Enrique López Garcés
Thank you Carlos - amazing research, discussion, and ideas. Great stuff.
Dane
_______________________________________________
Mapnik-users mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/mapnik-users
