Re: [OSM-dev] Improved text rendering in Mapnik
On Sat, 13 Oct 2012 14:11:41 +0200, Martin Koppenhoefer dieterdre...@gmail.com wrote: I am testing this and got the following error: [...] * attribute 'unlock-text' with value 'true' at line 6 This is a typo in the documentation. It's unlock-image instead of unlock-text. Should be fixed in a few minutes when github updates the page. BTW: I would propose to discuss issues with no direct relation to OSM on mapnik's mailing list only. Sorry for forgetting to include this notice in the original cross-post. Hermann ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] Improved text rendering in Mapnik
Hi! As my Google Summer of Code project I worked on improving Mapnik's text rendering. The most important change was adding support for complex scripts, but I also implemented some other nice features. You can read more about my work here: http://mapnik.org/news/2012/10/06/gsoc2012-status9/ Build instructions are included and I would like to hear about your success stories, but bug reports are also welcome. Hermann ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] GSoC - Improving support for non-latin languages in mapnik
Hello! I'd like to introduce my summer of code project Improving support for non-latin languages in mapnik A complete description and a process report are available at http://mapnik.org/news/2012/05/29/gsoc2012/ I'm still looking for test cases. So if you know a place where rendering goes wrong please inform me. Hermann ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] SoC Project: Preprocessor to add altitude information to OSM data
On Thu, 09 Apr 2009 12:32:23 +0200, Graham Jones (Physics) grahamjo...@physics.org wrote: Andy is right that the key to getting a true representation is not to just look at the altitude of nodes, but to integrate the SRTM data between the nodes to give total climb (the high tech version of counting the contour lines...). I think that is what Hermann was intending to do wasn't it? Yes that is what I was intending to do. Counting the contour lines is a really good explaination. In my application (http://r2d2.stefanm.com/soc2009/application2009_altitude.txt) I explicitly mentioned the project from last year: Some code should be resuable from last year's SRTM project by Sjors Provoost. However I also want to ADDITIONALLY add the altitude difference between two endpoints, as there might also be uses for this and it is trivial to compute when all the processing along the way is already done. Regards, Hermann ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] SoC Project: Preprocessor to add altitude information to OSM data
On Thu, 09 Apr 2009 08:43:40 +0200, marcus.wolsc...@googlemail.com wrote: With the relations it would be possible to publish only these new relations (so anybody can merge them with the corresponding planet-extract while also merging other data.) as no existing entities are modified. This sounds like a brilliant idea. The files with relations only should be small compared to the full planet dumps, so it would be easier to distribute them. I suggest changing the name to make it clear what point alt_total refers to and if distance is the 2d or 3d distance in meters. Names are open to discussion. I'm no native english speaker, so I'd like to hear some suggestions. Also note that not all nodes with a degree 2 are intersections of 2 roads. It may be something else intersecting (e.g. a node with the sign of a city may be shared by a road and a polygon surrounding the city or it may be 2 power-lines intersecting). These could easily be skipped. I'm planning to add a filter function that only selects ways that have certain tags. For example it would only process ways which have some kind of highway tag set. I would be willing to add support for your 3d-distance to the metrics for ShortestWay and StaticFastestWay and for the 3d-distance and and alt_difference to my incomplete metric that involves real physics (car accelerating, maximum speeds in sharp curves, ...). However for applications like this later metric alt_difference may be misleading as there may be 2 inclines and 1 decline between the 2 intersections. As I've written in my other mail I would compute two values: The difference in altitude between just then endpoints and a second and more important value which counts all the contour lines crossed. The second value will be the thing you use for routing. If required I could also add two more values one counting all inclines and one counting all declines. Regards, Hermann ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] SoC Project: Preprocessor to add altitude information to OSM data
Hello! I have applied for SoC to write an preprocessor that adds altitude data to ways to allow better bicycle routing, etc. The complete application text is available at [1] for those of you who don't have access to Google's mentor interface. First some information about me: I study physics at the University of Regensburg [2] and I'm in the 6th term. I already took part three times in SoC and completed all projects. My hobbies are computers, electronics, cycling and swimming. I could not discuss this proposal earlier, because I was very busy moving to a new house. Now that it's over I'll have more time. I got some questions about my application by Graham Jones grahamjones...@googlemail.com and I'll discuss then here: (Quotes are copied from his mail with permission, my replies are what I wrote him with some small corrections/additions) The first is what to do with the data - do you envisage it going back into the OSM database, or straight to the routing programme? There is a debate to be had about where to put this data - some may not wish to 'clutter' the OSM database with it. The data is not meant to go into the osm database, as it would result in incorrect data soon, as the users are free to move ways around. What I can imagine is that somebody processes the planetdump each week and publishes this dump. Something similar is done with routable garmin maps. This enables everybody to use the data without having to download all SRTM tiles and without the computing power. The other is slightly more fundamental - I agree that you can fairly easily calculate total climb over a way, but my question is whether that is really what you want? I think that most ways do not end at road junctions (certainly not the ones I have mapped anyway), but the routing programme will be interested in the total climb between road junctions, rather than for the total way? You are obviously right. What do you think about this idea: Instead of attaching tags to a way I could find all nodes which are shared by more than one way and then for each part of a way between two intersection create a relation like this: type=metainfo alt_difference=10.6 alt_total=27.3 distance=1032 with the way and the two intersection nodes as members. The distance is easily computed while doing the other processing. So the routing application could skip this step. If I am right then rather then your proposal will need closer integration with the routing programme - I think the router will pre-process the OSM file to calculate distance between junctions - we will want it to include altitudes at the same time. I explicitly tried to avoid a strong integration with the routers, because we have more than one and I expect even more in the future. Creating a library might be an option, if you think my idea is not really good the other way. However I still would prefer the preprocessor option since this allows to publish planet dumps which have the altitude information. When the processing is done by the router one has to publish data for each router seperatly or the user has to download the SRTM data. I want to make this application as userfriendly as possible and what could be more userfriendly than having a world file (or excerpt of it) which already includes the altitude data. I think your proposal to add a relation is an interesting one - it is essentially doing the same thing as the routing program will need to do for distances - you can imagine doing the same to calculate distance between junctions too, which is what the routing programs will do. I am still a little unsure how much benefit is gained by your proposed way of doing it, rather than directly incorporating it into a routing program - the routing program(s) will need to be modified to read your new relations anyway won't they? I would be inclined to suggest the two possibilities on your mailing list post to see what the others think. Of course the router will need some support for reading the data. But it won't need support for processing SRTM data directly. I'm also interested in some feedback on this point. What do the people on this mailinglist think about it? Regards, Hermann [1] http://r2d2.stefanm.com/soc2009/application2009_altitude.txt [2] http://www.uni-r.de/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
