On Wed, Sep 14, 2011 at 09:57:16AM +0200, Thorsten Kukuk wrote:

...

I tried to apply it on top of mkgmap-r2028, but it does not compile, toGarmingString is an unknown symbol. I disabled the two lines for now and I will testing it with my maps.

There is no toGarminString either.

Unfortunately, this patch did not get rid of a warning that I have been getting for some time now:

2011/09/14 09:08:58 WARNING (Subdivision): 63240010.osm.pbf: Subdivision width is 36627 at 3231057/1236133

Yes, that's a problem which is not yet addressed by the patch. I have some ideas how to fix that but it probably will take some time...

Here is how I generated the tile:

java -Xmx1024m -Dlog.config=logging.properties -jar mkgmap.jar --max-jobs --product-id=1 --code-page=1252 --adjust-turn-headings --remove-short-arcs --country-abbr=FIN --country-name=Finland --route --drive-on-right --check-roundabouts --check-roundabout-flares --report-dead-ends=2 --add-pois-to-areas --link-pois-to-ways --generate-sea=multipolygon --family-id=1 --family-name=OSM-14.09.2011 --location-autofill=nearest --description=Lappi --generate-sea=multipolygon,extend-sea-sectors --mapname=63240010 --input-file=63240010.osm.pbf

The tile comes from finland.osm.pbf with these splitter bounds:

63240010: 3067072,946400 to 3268608,1409024 # : 65.812225,20.307540 to 70.136719,30.234375

I guess I should split the tile at about 1236133 or halfway between 946400 and 1409024 to silence the warning.

Apart from multipolygon warnings (grep -vi multipolygon), only two warnings are generated for the tile:

2011/09/14 11:48:58 WARNING (MapBuilder): 63240010.osm.pbf: Highway 29 has no region (define a default region to zap this warning) 2011/09/14 11:49:08 WARNING (Subdivision): 63240010.osm.pbf: Subdivision width is 36627 at 3233496/1236133

Best regards,

Marko

WanMil

On Wed, Sep 14, 2011 at 08:21:16PM +0200, WanMil wrote:

...

...

Unfortunately, this patch did not get rid of a warning that I have been getting for some time now:

2011/09/14 09:08:58 WARNING (Subdivision): 63240010.osm.pbf: Subdivision width is 36627 at 3231057/1236133

Yes, that's a problem which is not yet addressed by the patch. I have some ideas how to fix that but it probably will take some time...

What are the potential implications of that problem? Will some polygon be omitted? Will routing be broken? Would it be possible to list the affected (or causing) OSM objects?

I don't know which implications that has. The width of the subdivision is too big for the zoom level and therefore the width is cut to 32767. So maybe some lines or shapes are not displayed that exceeds this width. It is not possible to list the OSM objects because the OSM ids are not available at this point. You might get rid of the error by splitting your tile at some point between longitude 1236133-36627/2 and 1236133+36627/2. WanMil

I tried splitting the tile into two:

63240010: 3067072,946400 to 3268608,1177712 # : 65.812225,20.307540 to 70.136719,30.234375 63240011: 3067072,1177712 to 3268608,1409024 # : 65.812225,20.307540 to 70.136719,30.234375

but it did not make the warning go away: 2011/09/15 10:28:07 WARNING (Subdivision): 63240011.osm.pbf: Subdivision width is 36627 at 3231057/1236133

Best regards,

Marko

On Wed, Sep 14, WanMil wrote:

...

Attached patch should fix (all?) subdivision splitting problems. Error like "Area too small to split at ..." cannot occur any more because the way how subdivisions are split is changed.

I tried to apply it on top of mkgmap-r2028, but it does not compile, toGarmingString is an unknown symbol. I disabled the two lines for now and I will testing it with my maps.

Oh, you are right. toGarminString() is a debug method in the Area class that outputs the borders in garmin units. I did not include that to the patch. Uncommenting these lines fixes that. WanMil

Am 14.09.2011 09:24, schrieb WanMil:

...

Attached patch should fix (all?) subdivision splitting problems. Error like "Area too small to split at ..." cannot occur any more because the way how subdivisions are split is changed.

I tested the 2028 and 2028 version with patch. Both seems to work. But for my test cases the patch was not needed.

I'm new to the mailing list because of the too small to split error. I was thinking that it takes longer to fix the problem and looked into the code and did write code to split also the shapes when the areas are splitted. This works but it expect that shapes are before splitting within the area boundaries.

Yes, at the moment only the center of the shape is guaranteed to be within the area (subdivision). The area has two bounds: an official bounds which is guaranteed to have an non exhausting size and the "full bounds" which contains the real dimension of all points, lines and shapes. When splitting the shape it is possible that the center of the new splitted shapes are no longer within the subdivision official bounds. That's the main problem of the current subdivison split algorithm. I think there are two main basic approaches how to fix that: 1. Drop the full bounds and split the shapes and lines on the official bounds. This has the advantage that you don't have an overlap of subdivisions and the disadvantage that you may get lots of additional points automatically created by the bounds splitting. 2. Drop the full bounds and create subdivisions by adding elements step by step until the subdivision limits are exhausted. This has the advantage that most of your subdivisions are maximally filled but the subdivisions will have a bigger overlap. I started to implement approach 2 but after thinking again about that approach 1 seems to be a good solution also (and with less changes to existing code).

This is not the case, and it stopped this, because it can't be proofed that it will work with any map. For debugging i did write a patch to generate overlays for Google earth to see the processing of mkgmap. This may of interest for you. The result files are to big for attaching, i put it on http://rlaib.de/mkgmap

gomera-2027.kmz is processed with mkgmap 2027 gomera-2028-type83.kmz is processed with mkgmap 2028 filtered to shape type 83 to make the file smaller. gomera-2028-wanmil.kmz is with the patch.

Thanks, looks interesting. Can you post your patch? WanMil

Hi Thorsten, there is not real progress on it. Maybe Gerd fancies to have a look on it if that's a good way to improve subdivision splitting? WanMil

Hi,

when looking at the patches I use for mkgmap I found that I'm still using this one. Are there any plans to contine work on this and apply it?

Thanks, Thorsten

Wed, Sep 14, WanMil wrote:

...

Attached patch should fix (all?) subdivision splitting problems. Error like "Area too small to split at ..." cannot occur any more because the way how subdivisions are split is changed.

I think it's still not the optimal way but there should be no loss in highly densed areas any more.

This is a first patch not ready to commit because there are some performance penalties which can be reduced. But I want you to test the patch before optimization.

WanMil