Re: [Maposmatic-dev] Document mo file generation from the po files in INSTALL
On Mon, Oct 14, 2013 at 09:43:46AM +0200, David MENTRE wrote: Hello Florian, 2013/10/9 Florian Lohoff f...@zz.de: this is my way how i generated the mo files from the po files. There might be a simpler way - just document it in the INSTALL file. Hmm, you'd probably better use i18n.py script, which *is* documented: ;-) http://git.savannah.gnu.org/cgit/maposmatic/ocitysmap.git/tree/I18N maposmatic@osmdb:~/ocitysmap$ grep i18n INSTALL | wc -l 0 So make it this: commit 206dcdcb89f5455f18b158258e1f0a07d0cad0e2 Author: Florian Lohoff f...@zz.de Date: Mon Oct 14 07:48:40 2013 + Document running the i18n.py for localization diff --git a/INSTALL b/INSTALL index 237e436..04bea05 100644 --- a/INSTALL +++ b/INSTALL @@ -266,6 +266,15 @@ are using. They have been tested on several x86_64 hosts. Create a ~/.ocitysmap.conf configuration file, modeled after the provided ocitysmap.conf.dist file. +e. Localization + +run + + ./i18n.py -m + +to create the ocitysmap.mo files for localization of e.g. the index. + + 12. Run OCitySMap ./render.py -t Ceci n'est pas Paris --osmid=-411354 # Contern, LU Flo -- Florian Lohoff f...@zz.de signature.asc Description: Digital signature
[Maposmatic-dev] Document mo file generation from the po files in INSTALL
Hi, this is my way how i generated the mo files from the po files. There might be a simpler way - just document it in the INSTALL file. Took me a while to find this. commit 17281de7c5586cd420e19f2400ab7dd26f69142a Author: Florian Lohoff f...@zz.de Date: Wed Oct 9 17:42:29 2013 + Add mo file generation from the po files to INSTALL diff --git a/INSTALL b/INSTALL index 237e436..8802714 100644 --- a/INSTALL +++ b/INSTALL @@ -266,6 +266,18 @@ are using. They have been tested on several x86_64 hosts. Create a ~/.ocitysmap.conf configuration file, modeled after the provided ocitysmap.conf.dist file. +e. Create mo files from po files + +Install the package + +sudo aptitude install gettext + +and then run the following command in the ocitysmap folder + +for i in locale/*/LC_MESSAGES; do ( cd $i ; msgfmt ocitysmap.po ; mv messages.mo ocitysmap.mo ); done + +to create the necessary mo files from the po file translations + 12. Run OCitySMap ./render.py -t Ceci n'est pas Paris --osmid=-411354 # Contern, LU -- Florian Lohoff f...@zz.de signature.asc Description: Digital signature
Re: [Maposmatic-dev] Document mo file generation from the po files in INSTALL
On Wed, Oct 09, 2013 at 07:49:25PM +0200, Jeroen van Rijn wrote: Hi Florian, Good thinking in documenting this. Perhaps it can be simplified further by using msgfmt's -o/--output-file option to directly write ocitysmap.mo? grmpf - i looked at the manpages 20 Times now but overlooked that :) So make it this: commit 17ef46089138996acecac323dfca8d26ce7d99a0 Author: Florian Lohoff f...@zz.de Date: Wed Oct 9 17:52:13 2013 + Add mo file generation from the po files to INSTALL diff --git a/INSTALL b/INSTALL index 237e436..6b213ee 100644 --- a/INSTALL +++ b/INSTALL @@ -266,6 +266,18 @@ are using. They have been tested on several x86_64 hosts. Create a ~/.ocitysmap.conf configuration file, modeled after the provided ocitysmap.conf.dist file. +e. Create mo files from po files + +Install the package + +sudo aptitude install gettext + +and then run the following command in the ocitysmap folder + +for i in locale/*/LC_MESSAGES; do msgfmt $i/ocitysmap.po -o $i/ocitysmap.mo; done + +to create the necessary mo files from the po file translations + 12. Run OCitySMap ./render.py -t Ceci n'est pas Paris --osmid=-411354 # Contern, LU -- Florian Lohoff f...@zz.de signature.asc Description: Digital signature
Re: [Maposmatic-dev] ocitymap patch - grid label overlap
Hi David, On Fri, Sep 27, 2013 at 07:55:19AM +0200, David MENTRE wrote: Hello Florian, 2013/9/23 Florian Lohoff f...@zz.de: what do you think of this modification? IMHO its ugly that grid labels overlap in the grid corners. I agree on the approach. I wanted to check the current layout but maposmatic.org is currently down (big issue at the hosting company). On your patch, maybe you could add some short comments telling what are doing your if statements. Have you checked that your patch works correctly with the different kind of layouts? I havent - But in the end whenever we put the labels in the corner we want to avoid putting 2 of them in the same corner. The example in the commit message shows which of them gets eliminated. Sorry for the late feedback, but better later than never. ;-) Same patch - whitespace corrected (i used tabs) and with a short comment. commit dcc1351a26b0a385fa3c5ba8fb30c5d8ccef9317 Author: Florian Lohoff f...@vitroconnect.de Date: Wed Oct 2 08:08:42 2013 + Clear the corners of duplicate labels The grid corners typically get a vertical and a horizontal label. These do overlap from a certain scale on. Avoid by printing only one label: A B C 1 2 2 3 3 4 B C D diff --git a/ocitysmap/layoutlib/abstract_renderer.py b/ocitysmap/layoutlib/abstract_renderer.py index 86a7483..6458566 100644 --- a/ocitysmap/layoutlib/abstract_renderer.py +++ b/ocitysmap/layoutlib/abstract_renderer.py @@ -196,11 +196,16 @@ class Renderer: else: continue -draw_utils.draw_simpletext_center(ctx, label, - x, grid_legend_margin_dots/2.0) -draw_utils.draw_simpletext_center(ctx, label, - x, map_area_height_dots - - grid_legend_margin_dots/2.0) +# At the top clear the right corner of the horizontal label +if (i map_grid.horiz_count-1): +draw_utils.draw_simpletext_center(ctx, label, + x, grid_legend_margin_dots/2.0) + +# At the bottom clear the left corner of the horizontal label +if (i 0): +draw_utils.draw_simpletext_center(ctx, label, + x, map_area_height_dots - + grid_legend_margin_dots/2.0) for i, label in enumerate(map_grid.vertical_labels): y = i * step_vert @@ -212,9 +217,14 @@ class Renderer: else: continue -draw_utils.draw_simpletext_center(ctx, label, +# On the left clear the upper corner of the vertical label +if (i 0): +draw_utils.draw_simpletext_center(ctx, label, grid_legend_margin_dots/2.0, y) -draw_utils.draw_simpletext_center(ctx, label, + +# On the right clear the bottom corner of the vertical label +if (i map_grid.vert_count -1): +draw_utils.draw_simpletext_center(ctx, label, map_area_width_dots - grid_legend_margin_dots/2.0, y) -- Florian Lohoff f...@zz.de signature.asc Description: Digital signature
[Maposmatic-dev] ocitymap patch - grid label overlap
Hi, what do you think of this modification? IMHO its ugly that grid labels overlap in the grid corners. commit 6dc059a058af5f9dd1b5411100072aadaacdf7bb Author: Florian Lohoff f...@zz.de Date: Mon Sep 23 16:33:33 2013 + Never print 2 labels in the grid corner The grid corners typically get a vertical and a horizontal label. These do overlap from a certain scale on. Avoid by printing only one label: A B C 1 2 2 3 3 4 B C D diff --git a/ocitysmap/layoutlib/abstract_renderer.py b/ocitysmap/layoutlib/abstract_renderer.py index 86a7483..e74fd47 100644 --- a/ocitysmap/layoutlib/abstract_renderer.py +++ b/ocitysmap/layoutlib/abstract_renderer.py @@ -196,11 +196,14 @@ class Renderer: else: continue -draw_utils.draw_simpletext_center(ctx, label, - x, grid_legend_margin_dots/2.0) -draw_utils.draw_simpletext_center(ctx, label, - x, map_area_height_dots - - grid_legend_margin_dots/2.0) + if (i map_grid.horiz_count-1): + draw_utils.draw_simpletext_center(ctx, label, + x, grid_legend_margin_dots/2.0) + +if (i 0): +draw_utils.draw_simpletext_center(ctx, label, + x, map_area_height_dots - + grid_legend_margin_dots/2.0) for i, label in enumerate(map_grid.vertical_labels): y = i * step_vert @@ -212,9 +215,12 @@ class Renderer: else: continue -draw_utils.draw_simpletext_center(ctx, label, +if (i 0): +draw_utils.draw_simpletext_center(ctx, label, grid_legend_margin_dots/2.0, y) -draw_utils.draw_simpletext_center(ctx, label, + +if (i map_grid.vert_count -1): +draw_utils.draw_simpletext_center(ctx, label, map_area_width_dots - grid_legend_margin_dots/2.0, y) -- Florian Lohoff f...@zz.de signature.asc Description: Digital signature
Re: [Maposmatic-dev] [mapnik] Re: cairo null pointer
On Thu, Sep 19, 2013 at 10:48:03PM -0700, Dane Springmeyer wrote: Flo, would it be possible to create a simple, reduced testcase that can trigger this error outside of maposmatic? In Mapnik 2.2 we refactored the code to drop the dependency on cairomm. There may therefore be issues with this new code. Puh - My python knowledge is basically non-existant - as is the knowledge about cairo, mapnik and the other internals :) I tried around a bit but it'll take some time. BTW i had the same bug with mapnik head. I tried mapnik commit id c88fcc8f which was mentioned in the maposmatic INSTALL as working and indeed it works. Flo -- Florian Lohoff f...@zz.de signature.asc Description: Digital signature
[Maposmatic-dev] cairo null pointer
Hi, i am trying to run render.py on a Debian/Wheezy with mapnik of yesterday and get a very helpful error message of cairo. As the path implies its the Debian/Wheezy cairo. Too old cairo? Too new mapnik? maposmatic@osmdb:~/ocitysmap$ ./render.py -t Rheda --osmid=-78727 -L de_DE.UTF-8 -l plain --orientation=landscape DEBUG:ocitysmap:Reading OCitySMap configuration from /home/maposmatic/.ocitysmap.conf... DEBUG:ocitysmap:Found 1 Mapnik stylesheets. DEBUG:ocitysmap:Looking up bounding box and contour of OSM ID -78727... INFO:ocitysmap:Connecting to database maposmatic on localhost:5432 as maposmatic... DEBUG:ocitysmap:Configured statement timeout: 15min. DEBUG:ocitysmap:Looking up bounding box and contour of OSM ID -78727... DEBUG:ocitysmap:Map represents 13809x12052m, needs at least 233.1x203.5cm on paper. DEBUG:ocitysmap:Best fit is 239.0x224.8cm. INFO:ocitysmap:Rendering with renderer plain in language: de_DE.UTF-8 (rtl: False). DEBUG:ocitysmap:Looking up bounding box and contour of OSM ID -78727... DEBUG:ocitysmap:Looking up bounding box and contour of OSM ID -78727... DEBUG:ocitysmap:Rendering in temporary directory /tmp/ocitysmapZzmCwL INFO:ocitysmap:Rendering to PDF format... INFO:ocitysmap:Getting streets... DEBUG:ocitysmap:Got 662 streets. INFO:ocitysmap:Getting amenities for Places of worship/place_of_worship... DEBUG:ocitysmap:Got 9 amenities for Places of worship/place_of_worship. INFO:ocitysmap:Getting amenities for Education/kindergarten... DEBUG:ocitysmap:Got 13 amenities for Education/kindergarten. INFO:ocitysmap:Getting amenities for Education/school... DEBUG:ocitysmap:Got 33 amenities for Education/school. INFO:ocitysmap:Getting amenities for Education/college... DEBUG:ocitysmap:Got 33 amenities for Education/college. INFO:ocitysmap:Getting amenities for Education/university... DEBUG:ocitysmap:Got 33 amenities for Education/university. INFO:ocitysmap:Getting amenities for Education/library... DEBUG:ocitysmap:Got 34 amenities for Education/library. INFO:ocitysmap:Getting amenities for Public buildings/townhall... DEBUG:ocitysmap:Got 2 amenities for Public buildings/townhall. INFO:ocitysmap:Getting amenities for Public buildings/post_office... DEBUG:ocitysmap:Got 3 amenities for Public buildings/post_office. INFO:ocitysmap:Getting amenities for Public buildings/public_building... DEBUG:ocitysmap:Got 7 amenities for Public buildings/public_building. INFO:ocitysmap:Getting amenities for Public buildings/police... DEBUG:ocitysmap:Got 9 amenities for Public buildings/police. DEBUG:ocitysmap:Got 2 villages for Villages. DEBUG:ocitysmap:Corrected bounding box from BoundingBox(51.8980,8.1996 51.7896,8.4009) to BoundingBox(51.8982,8.1996 51.7895,8.4009), ratio: 1.14. INFO:ocitysmap:MapCanvas rendering map on 6744x5896px. DEBUG:ocitysmap:Created layer shade in PolyShapeFile /tmp/ocitysmapZzmCwL/shade.shp. DEBUG:ocitysmap:Added shape file /tmp/ocitysmapZzmCwL/shade.shp to map canvas as layer shade. INFO:ocitysmap:Laying out grid on 13809.1x12086.8m area... INFO:ocitysmap:Using 250.0x250.0m grid (55.2365618296x48.3472078381 squares). DEBUG:ocitysmap:Created layer grid in LineShapeFile /tmp/ocitysmapZzmCwL/grid.shp. DEBUG:ocitysmap:Added shape file /tmp/ocitysmapZzmCwL/grid.shp to map canvas as layer grid. DEBUG:ocitysmap:Creating CSV file citymap.csv... INFO:ocitysmap:SinglePageRenderer rendering on 2390x2248mm paper at 72 dpi. DEBUG:ocitysmap:Mapnik scale: 1/11864.514489 DEBUG:ocitysmap:Actual scale: 1/5856.905729 DEBUG:ocitysmap:Cleaning up /tmp/ocitysmapZzmCwL... Traceback (most recent call last): File ./render.py, line 243, in module sys.exit(main()) File ./render.py, line 238, in main options.output_prefix) File /home/maposmatic/ocitysmap/ocitysmap/__init__.py, line 462, in render file_prefix) File /home/maposmatic/ocitysmap/ocitysmap/__init__.py, line 521, in _render_one renderer.render(surface, dpi, osm_date) File /home/maposmatic/ocitysmap/ocitysmap/layoutlib/single_page_renderers.py, line 408, in render ctx.restore() cairo.Error: NULL pointer python: /tmp/buildd/cairo-1.12.2/src/cairo.c:301: cairo_destroy: Assertion `((*(cr-ref_count)-ref_count) 0)' failed. Aborted -- Florian Lohoff f...@zz.de signature.asc Description: Digital signature
Re: [Maposmatic-dev] cairo null pointer
On Thu, Sep 19, 2013 at 10:41:00AM +0200, Florian Lohoff wrote: Hi, i am trying to run render.py on a Debian/Wheezy with mapnik of yesterday and get a very helpful error message of cairo. As the path implies its the Debian/Wheezy cairo. Too old cairo? Too new mapnik? Same behaviour with mapnik 2.2 from sid compiled for wheezy ... Traceback (most recent call last): File ./render.py, line 243, in module sys.exit(main()) File ./render.py, line 238, in main options.output_prefix) File /home/maposmatic/ocitysmap/ocitysmap/__init__.py, line 462, in render file_prefix) File /home/maposmatic/ocitysmap/ocitysmap/__init__.py, line 521, in _render_one renderer.render(surface, dpi, osm_date) File /home/maposmatic/ocitysmap/ocitysmap/layoutlib/single_page_renderers.py, line 408, in render ctx.restore() cairo.Error: NULL pointer python: /tmp/buildd/cairo-1.12.2/src/cairo.c:301: cairo_destroy: Assertion `((*(cr-ref_count)-ref_count) 0)' failed. Aborted Flo -- Florian Lohoff f...@zz.de signature.asc Description: Digital signature
Re: [Maposmatic-dev] place=locality #9699
On Wed, Sep 12, 2012 at 08:53:58AM +0200, David MENTRE wrote: Hello Florian, This is what is currently done: http://git.savannah.gnu.org/cgit/maposmatic/ocitysmap.git/tree/ocitysmap/indexlib/indexer.py#n412 where trim(name) != '' and (place = 'locality' or place = 'hamlet' or place = 'isolated_dwelling') As as said, for this particular bug the issue is not technical but political. What is the general OSM worldwide consensus about the use of such tags? Is there such a consensus? Initialy i said place=locality is something which should not show up in Villages. The Wiki explicitly mentiones it as an uninhabited location. So it cant be a village. http://wiki.openstreetmap.org/wiki/Tag:place%3Dlocality The place=locality tag can be used to name unpopulated place which is not associated with any extant feature to which such a tag could be associated http://wiki.openstreetmap.org/wiki/DE:Key:place Flurbezeichung. Name eines Ortes, wo keine Leute Leben (Flurname). Here the German and the English version differ a bit - But both agree that its an unpopulated place. The German documentation even goes further and makes it a Flurbezeichnung which is a legal name for the land registry. Flo -- Florian Lohoff f...@zz.de signature.asc Description: Digital signature
Re: [Maposmatic-dev] place=locality #9699
Hi, On Thu, Sep 06, 2012 at 03:32:51PM +0200, David MENTRE wrote: Hello Florian, 2012/5/30 Florian Lohoff f...@zz.de: place=locality is by its explanation not a suburb/village or something but just a name for a place. I have used to name well known places with their name which do not have any physical representation e.g. building/street etc .. In the generated map this shows up as Dörfer e.h. Villages which is IMHO wrong ... So with the place= tags the locality should be excluded to show up on the generated maps index. It appears that there is a local use issue here. At least in France, it seems correct to include place=locality in Index (see https://savannah.nongnu.org/task/index.php?9699 for details). But according to your bug report this is not the case in Germany. I don't know how to solve such issue. Would you have some reference OSM sources to help us make a decision? http://wiki.openstreetmap.org/wiki/Key:place I just talk about place=locality which is from the OSM Wiki an For an unpopulated named place. So it cant be a Village or Dorf. Its a named place. So i think putting place=hamlet and/or isolated_dwelling into the index Villages would be okay - but place=locality is not. BTW, it would be much preferable to talk about such issue on the public dev@ mailing list. Just subscribed and CCed Flo -- Florian Lohoff f...@zz.de signature.asc Description: Digital signature
Re: [Maposmatic-dev] place=locality #9699
On Fri, Sep 07, 2012 at 10:06:27AM +0200, David MENTRE wrote: Hello Florian, 2012/9/7 Florian Lohoff f...@zz.de: http://wiki.openstreetmap.org/wiki/Key:place I just talk about place=locality which is from the OSM Wiki an For an unpopulated named place. So it cant be a Village or Dorf. Its a named place. Unfortunately, French mappers have a different view: https://wiki.openstreetmap.org/wiki/FR:Key:place Le tag place est une indication de ville, village, hameau, etc. In English: place tag is an indication of city, village, hamlet, etc.. I am not saying that the French view is better than the German one or the reverse. Just that there is a disagreement and if we remove place=locality from Index, we'll get angry messages from French mappers. :-) There is a multitude of place= values which are definitly not a Village/City farm continent county island locality region state These should all be ignored when building the index for Villages. It should more be a positive list of tag values which get listed - something like: town village hamlet isolated_dwelling suburb There should be some duplicate eliminating when the name shows up in the Map title. e.g. dont list Gütersloh when that shows up in the map title ... Flo -- Florian Lohoff f...@zz.de signature.asc Description: Digital signature
