Hello Herm, I wanted to give some public feedback on your project proposal to help get things started.
Congrats again on your acceptance, and thanks for choosing to work on the Mapnik project. I hope that you can send more emails to the mapnik-devel list, with questions and comments, and emails to both mapnik-devel and mapnik-users when you have announcements of things to test. As you lead mentor, I'd like to see you follow our other student, Carlos's project as you work. He, and his mentor Artem, may be looking into writing a custom SVG renderer near the latter part of his project. As you have worked on osmarender, and are also familiar with SVG through your work with the Scribus project/Cairo, I am sure your involvement/advise will be appreciated. In addition, I'd also like to see you document and share a little more about how you think that the Google Apis clickable labels work. I have seen this feature on gmaps, but not taken the time to investigate closely how it works. If you could provide a summary + a few screenshots, then I'm sure this example will help other Mapnik users and developers see the subtle but very nice feature it is, and how it is certainly tied to the intelligence of the tile renderer and not a separate process. Now, more comments line.... On Apr 8, 2010, at 5:33 PM, Hermann Kraus wrote: > Hello! > > I'm a physics student applying for this year's summer of code. I've written a > proposal and would like to get comments from the community. I've attached the > proposal to this email. Please comment on it to, so I know if it is good or > what could be changed. > > Thanks everybody for your help! > > Regards, > > Hermann Kraus > > > Short description > ----------------- > The goal of this project is to implement functionality to output metadata to > make certain things on the map clickable. I'll add tools to make the common > use cases very easy for the user. > It will also be good to give thought to how to expose these features in Mapnik's XML stylesheets, so that users can easily decide which layers (or perhaps even styles, if more than style pulls from a layer), are clickable, and with what metadata. Layer's currently have a queryable="<bool>" parameter which is used to determine whether the feature should be able to be queried from a WMS server that supports GetFeatureInfo. Something similiar to that parameter may be in order. Herm, are you familiar with GetFeatureInfo from the WMS spec? If not I would like you to research it, since it is standards based. My understanding is that it is designed to allow feature queryablity without regard to what features would be rendered on a bitmap, so it is a very different thing than your proposal, but an important comparison nontheless. Mapnik's (unmaintained) ogcserver supports clickable metadata through GetFeatureInfo, although it does not work very well. I have gotten it working with Quantum GIS with this change: http://bitbucket.org/springmeyer/ogcserver/changeset/1f008475c926 > Rationale > --------- > Having maps with clickable objects makes it easier for the user to obtain > information about objects on the map. Since a few month Google Maps enables > you to click on a restaurant, tourist attraction, etc. icon on the map and > more data is displayed. Currently maps created with Mapnik can't easily do > this, because Mapnik only outputs the bitmap data but no information about > where features have been placed. If one tries to do it one has to project the > clickable features by another program. This is unnecessary work and not > always possible. Absolutely. Been there, and your below ideas offer exciting potential solutions. > For example when there is no icon but a text label it will be very hard to > determine the actual size of the label. > I expect this to get worse in the future when Mapnik's placement algorithms > get more intelligent. Yes, very very good observation. We plan to add the ability to logically shift (by certain tolerance) labels around a point in the future (https://trac.mapnik.org/ticket/463), as well as other such improvements whose intelligence would be difficult to impossible to mirror in some separate clickable serverside tool to query features. > For example it might decide to move a road a few pixel to make place for > another road, combine multiple icons into one, … > yes, yes..., or shift a line to the side (https://trac.mapnik.org/ticket/180) (though most utility will relate to point placement I assume). > Motivation > ---------- > I really like Mapnik's clean rendering style and would like to make it even > more useful by enabling users to click on features, no matter where Mapnik > decided to place them. For example OpenStreetMap would profit much from this > change, as there is a lot of information in the database which is not > rendered at the moment. Yes, but good enough start just to make clickable the features that are rendered, so that there additional info (other fields/columns of attribute data) is available (maybe this is what you mean?). A further step could be thinking through pulling in metadata from an object reference of some sort, table, url, etc. > It could be made available by clicking on objects (just like Google does now). As per above, hoping that you can provide additional info about how you think Google works currently, how we could do even better :) > Currently it would be quite complex to do this because a second projection > pass by different software would be required and it might break with future > improvements in Mapnik (as described above). It also could happen that some > features are suppressed during rendering which would still be clickable and > therefore confuse the user. yup, certainly common problems that I have seen which this would solve nicely. > Why did I choose this project: Looking for a project I also checked Mapnik's > open trac tickets and but most things there looked like they wouldn't be > suited for a summer of code project. I think this project will really help a > lot of users and perhaps some new users will discover Mapnik. Yes, certainly. > > Implementation idea > ------------------- > At the point during processing at which an object (line, polygon, text) is > actually output to the final image the geometry data is captured together > with an user definable object property (object ID, street name, …) and > written to a metadata section. For more complex features post processing > might be required that combines features to reduce the amount of data. Yes, so right now I see this happening inside agg_renderer.cpp or cairo_renderer.cpp + placement_finder.cpp. Perhaps after getting metadata collection working within the actual renderer code, you could think about ways to make it more generic, perhaps through subclassing. Involving Artem Pavlenko in the question of how existing renderers might be extended/designed with this flexibility in mind will be important. > > Output format > ------------- > I intend to make the output as flexible as possible. Probably there will be > different output methods for different needs. Yes, I see the critical thing as the impl, and the format could be varied. Ideally it could be lightweight and web friendly, but I am interested in your db ideas below as well. Seems like SQLite might be a good candidate (added benefit of maybe getting ideas from HTML5 web storage methods that use SQLite from within browser). > Some examples I can think of: > - Writing the data to a database (PostGIS, etc.) which is queried when the > user clicks somewhere (for large scale projects/many clickable feature per > tile). This seems to be the way Google Maps works. > - Writing a file with geometry information and some kind of ID (e.g. > node/way-ID) or URL for each tile produced (for systems without a database > backend). > - Writing one big file for the whole area covered with preprocessed > description texts, that can be displayed as popup texts. Useful for small or > standalone systems without permanent internet connection. This format would > probably be directly compatible with OpenLayers vector layer [1]. > - For SVG output it might be possible to add some more tags to SVG objects > which contain IDs. So the geometry is not duplicated. > - The project idea page in the wiki lists EXIF as a possible output format. > This might be well suited because all data is contained in one file, but it's > hard to read EXIF data in JavaScript which is the main platform for clickable > maps. I was able to find only one JavaScript EXIF implementation and it > doesn't work in all browsers. Yes, great ideas. They certainly all have benefits. I know the Javascript EXIF may not be compatible with IE, but is could be very slick in the future as support came online (I presume browsers supporting Canvas would also support JS libs that can parse EXIF directly from the image?) > > Of course the implementation and output formats are open to suggestions. > Yes. My tendency would be to start with sqlite, as a balance of efficiently and portability, but I am open to suggestions. Something that was file based and could be directly parsed by OpenLayers would also be very useful.... > Deliverables > ------------ > - Patches to add the required functionality Ideally I'd like to see you work either directly on trunk (after initial patches), or in a branch within mapnik svn. > - Examples of how to produce clickable maps Great. Again would be nice to see a write up soon for all Mapnik community to understand concept soon, and you could use Google Maps as an example. > - Tools to simplify this process and make it available to everyone > Great, we should discuss this more, try to get ideas of the right implementation. > > Timeline > -------- > April 26: Accepted student proposals announced on the Google Summer of Code > 2010 site. > Community Bonding Period: Students get to know mentors, read documentation, > get up to speed to begin working on their projects. > > I'll familiarize myself with the Mapnik codebase, discuss the formats, > requirements, etc. I expect to start coding during this period already > because this is usually a quiet time at university. Great, I am out of town for the next two weeks in Haiti, so I may not be able to response, but I will check email. Please email the mapnik-devel list with any questions and comments on progress, as you start coding. I also strongly encourage you to pick a few Trac tickets to work on as well, so allow yourself opportunities to see other parts of the Mapnik code base. > > May 24: Students begin coding for their GSoC projects; Great, I will return from Haiti on the 24th. > > At this point I should be familiar with the code and write the basic > implementation (one output format). > > I expect to be busy with exams directly before the mid-term evaluation, but > they should not last long. > > July 12: Mentors and students can begin submitting mid-term evaluations. > > I'll have a working code at mid-term. After that date I'll add more advanced > output options, configuration options and write documentation. > To help users of my code I'll create some examples how to use it with > OpenLayers. > Great. > August 9: Suggested 'pencils down' date. Take a week to scrub code, write > tests, improve documentation, etc. > > All code will be ready, I can do some cleanups afterwards. > > August 16: Firm 'pencils down' date. Mentors, students and organization > administrators can begin submitting final evaluations to Google. > August 20: Final evaluation deadline > > I expect this timeline to be very conservative and I should have plenty of > time if unforeseen difficulties appear. If I'm done earlier I will work on > other things related to this project. Examples: Moving icons/text a bit that > can't be placed at the position it should go to because there is another > icon/text. Or combining multiple icons into one (however I'm not sure this is > easily doable as it will take two passes to place icons). These improvements > would help to make sure as many features as possible are drawn and therefore > maximize the amount of clickable objects shown. > Okay, looking forward to talking more about label placement if there is time. Cheers! Dane _______________________________________________ Mapnik-users mailing list [email protected] https://lists.berlios.de/mailman/listinfo/mapnik-users
