- mkgmap-dev - The mkgmap lists

Analysis of MP issues in Finland
by Marko Mäkelä 29 Jan '10

29 Jan '10

Hi WanMil, Mark, all, I analyzed all the multipolygon errors and warnings I got for today's finland.osm.bz2 from Geofabrik, without --generate-sea. Most of them can apparently be blamed on missing boundary information. I wrote the relation IDs an explanations to my logging.ignore file, so that I will not have to see these messages again. You can get the file from http://www.polkupyoraily.net/osm/, but I will repeat the interesting bits here: # overlapping lines in multipolygons, should be fixed in mkgmap later http://www.openstreetmap.org/browse/relation/48542 http://www.openstreetmap.org/browse/relation/367049 http://www.openstreetmap.org/browse/relation/372975 http://www.openstreetmap.org/browse/relation/387793 http://www.openstreetmap.org/browse/relation/389976 # multipolygon problem at tile border, should be fixed in mkgmap or splitter http://www.openstreetmap.org/browse/relation/302897 http://www.openstreetmap.org/browse/relation/306274 http://www.openstreetmap.org/browse/relation/311221 (the offending tile border is at lat=62.226562; the other one is at lat=64.819336) I could not see what is causing the following issues. WanMil, can you please analyze these? One of them was edited recently, but the other was not, as far as I can tell: 2010/01/29 12:11:44 WARNING (MultiPolygonRelation): 63240001.osm.gz: Multipolygon http://www.openstreetmap.org/browse/relation/372970 contains intersected or overlapping ways 2010/01/29 12:11:44 WARNING (MultiPolygonRelation): 63240001.osm.gz: Multipolygon http://www.openstreetmap.org/browse/relation/375636 contains intersected or overlapping ways Last but not least, here is an idea for quality control. I came across two lakes whose islands were in another lake (the change message hinted that the lake had been split). There is no warning for that. The errors must be coming from missing boundary information in the Geofabrik extract. http://www.openstreetmap.org/browse/relation/303320 http://www.openstreetmap.org/browse/relation/303321 Best regards, Marko

2 3

Commit: r1538: Print expected result rather than repeating the actual result.
by svn commit 29 Jan '10

29 Jan '10

Version 1538 was commited by steve on 2010-01-29 18:14:52 +0000 (Fri, 29 Jan 2010) BRANCH: style Print expected result rather than repeating the actual result.

1 0

--add-pois-to-areas behaviour
by Christoph Wagner 29 Jan '10

29 Jan '10

Hi list, I found an issue with the --add-pois-to-areas option and don't know if it's a bug or a feature. Areas get only converted to points, if there is a matching rule in the points-style file AND if there is a matching rule in the polygons file. I don't understand the second condition. Imagine I want to show buildings only as a single point and no area. So it would be very useful to get building polygons converted to a point without specifiing it in polygons file. The dirty hack at the moment is to specify a rule in polygons and make the whole area transparent with a typfile, just to get a point created. But this is really stupid, because the polygon exist and the mousepointer could not show what is under this area. Can somebody help me? Christoph

3 7

Duo Tagged polygon.
by Dave F. 29 Jan '10

29 Jan '10

Hi My last question got missed (Polygon with barrier problem) but I would like to know the answer so I'm posting it again. As discussed (polygon) landuse=farmyard & barrier=wall wont render landuse if (line) barrier=wall is present. Is there any development in progress to solve this problem? "mkgmap processes the style files in a strict order..." As I said, I'm a newbie so I may not understand fully, but wouldn't it be better if, when mkgmap reads the OSM file & it finds a polygon (first point=last point) then it should look directly in the polygon file? To me it seems a illogical to have an order. On a more general note, As this is the only forum for mkgmap, would it be worth setting up general question one so that queries by newbies like me don't get hidden in amongst the busy coders here? Cheers Dave F.

4 6

Unchecked conversions and calls
by Marko Mäkelä 29 Jan '10

29 Jan '10

I am compiling mkgmap with Sun javac with -Xlint:unchecked by commenting out the compilerarg definition in build.xml, and I get some warnings for unchecked calls and type conversions. I do not know Java well enough to fix these (I learned it before the generics were introduced and have not written much Java lately). I guess that some <classname> qualifiers would have to be added. Could someone please look at these? Marko

1 0

Commit: r1536: Warn if light period is too large to be encoded (and limit to max allowed).
by svn commit 28 Jan '10

28 Jan '10

Version 1536 was commited by markb on 2010-01-28 22:35:08 +0000 (Thu, 28 Jan 2010) Warn if light period is too large to be encoded (and limit to max allowed). At this time, we can encode light-light periods up to 51.1 seconds and buoy-light periods up to 25.5 seconds.

1 0

Commit: r1535: Further work on avoiding duplicate boundary nodes when generating sea.
by svn commit 28 Jan '10

28 Jan '10

Version 1535 was commited by markb on 2010-01-28 22:07:32 +0000 (Thu, 28 Jan 2010) Further work on avoiding duplicate boundary nodes when generating sea.

1 0

Support for seamark tags in default style
by Mark Burton 28 Jan '10

28 Jan '10

Hi Marko, I haven't changed the seamark style stuff for a while now so I wonder if the attached rules could be incorporated into the default style so that anyone can generate maps with lights & buoys, etc. Mark PS - did you try the patch I posted yesterday to fix the error messages you were seeing when generating sea?

3 8

Commit: r1534: Restore the default uppercasing of labels.
by svn commit 28 Jan '10

28 Jan '10

Version 1534 was commited by steve on 2010-01-28 21:10:52 +0000 (Thu, 28 Jan 2010) Restore the default uppercasing of labels.

1 0

General tagging problem in multipolygons
by WanMil 28 Jan '10

28 Jan '10

My last patch shows a conflict that the mulitpolygon code cannot win. Example: ==== A mp can consist of several ways: Way 1: man_made=pier; natural=water (yeah the pier is part of the border of a lake) Way 2: natural=water Way 3: natural=water; boundary=administrative (this way will be part of another boundary mulitpolygon) Way 4: without any tags Way 1 to 4 build up the complete lake. After constructing the multipolygon I have different options: 1. Remove all polygon tags from the original ways - This removes the man_made=pier information from way1 although we would like to have it - This removes the boundary tag from way3 although we might need it for processing the boundary multipolygon 2. Leave all tags as they are - This possibly creates flooding for all three ways. Some parts of mkgmap seem to autoclose ways if they contain polygon tags. I don't understand where it happens but I have seen it several times in finnland. (e.g. the big lake near Ikaalinen, multipolygon 303327) 3. Leave all tags as they are but mark them as mp-used. All mp-used tags will be removed after all multipolygons have been processed. - This makes the boundary multipolygon work. - The first way is still a problem. How should I know if man_made=pier should be a tag for the multipolygon? ========= The solution is that all multipolygons (at least all mps with multiple unclosed outer ways) are tagged themselves. But the reality is different. Most multipolygons get their tags from the ways. Another solution could be that ways get an "used by mp" tag so that other steps in mkgmap don't try to autoclose these ways. This would give a chance to option 2. What do you think? Any ideas about good solutions for the tagging problem? WanMil

2 1