[mkgmap-dev] SeeGenerator error with r1752

Fri Dec 24 08:02:49 GMT 2010

Hi WanMil,

>1. A synchronization in the MapMaker class was removed. Do you use more
>than 1 thread?

Yes, I use --max-jobs, with 2 threads (Intel Core Duo L2400). The log 
from r1728 seemed to contain more warnings. Could the new mkgmap be 
silently dropping some features?

>2. The procedure how the list of relevant tags that are read from the
>OSM file is created was changed a bit. Maybe this introduced a bug so
>that some things are missing now. Can you do a quick check, if you are
>missing some POIs or highways or polygons in the r1753 map?

Here are the most recent log files, all on 6 osm.gz tiles split from 
yesterday's finland.osm.pbf:

-rw-r--r-- 1 marko marko 3855193 23.12. 22:24 mkgmap.log.0  r1753
-rw-r--r-- 1 marko marko   19309 23.12. 22:06 mkgmap.log.1  r1752, NPE
-rw-r--r-- 1 marko marko  322567 23.12. 10:55 mkgmap.log.2  r1728

In r1753, the growth could be due to an error in generate-sea. Here is 
an example:

2010/12/23 22:22:11 WARNING (MultiPolygonRelation): 63240001.osm.gz: 
Multipolygon 
http://www.openstreetmap.org/browse/relation/4611686018427403589 
contains errors.
2010/12/23 22:22:11 WARNING (MultiPolygonRelation): 63240001.osm.gz: 
Some polygons are intersecting. This is not allowed in multipolygons.
2010/12/23 22:22:11 WARNING (MultiPolygonRelation): 63240001.osm.gz: - 
http://www.openstreetmap.org/browse/way/4611686018427403617
...

The NullPointerException in r1752 seemed to occur very late in the 
processing, after writing everything to the log. The shrinkage from 
r1728 to r1752 log output is due to stuff like this that r1752 no longer 
complains about:

2010/12/23 10:51:12 WARNING (RoadDef): 63240001.osm.gz: (^E4/7 
Meritullintori, http://www.openstreetmap.org/browse/way/30287920) 
discarding extra label (already have 4)
2010/12/23 10:51:12 WARNING (RoadDef): 63240001.osm.gz: (^E4/7 
Meritullintori, http://www.openstreetmap.org/browse/way/35148621) 
discarding extra label (already have 4)

The way names look like highway=trunk or highway=primary, and presumably 
they all belong to a route relation, such as 
http://www.openstreetmap.org/browse/relation/67630 (European Route 75).

>3. The procedure how the mulitpolygon processing removes tags from the 
>original ways was changed. Either this introduced or fixed a bug. ?!?

The above ways do not belong to a multipolygon, only to a route relation 
and a turn restriction relation.

>Yeah, it is possible that the old algorithm missed some tag removals on 
>lines and polygons so that the number of objects was too large in the 
>maps.

Could you have improved this 'discarding extra label' too?

>It would be great if we have a tool that reads the IMG-file and creates 
>a statistic of how many objects are contained in the file. Do we have 
>that already?! I think I remember a thread about that but I cannot find 
>it.

IIRC, there is something in the mkgmap svn repository, presumably 
written by Steve in the very early stages of mkgmap. I have never used 
it. There could also be something on SourceForge(t), in a Garmin 
reverse-engineering project.

	Marko