.poly file - coordinate accuracy

[ogrums]

Hello, I'm having problems with coordinates in a .poly file for a large map, and have boilt the problem down to this simple example:

I have a region (3.2-3.4,42.2-42.5) and this .poly:

Code: Alles auswählen

gpx2poly.awk
1
   3.25000  42.20000
   3.35000  42.30000
   3.30000  42.40000
   3.25000  42.35000
END
END

1. when i make a map with the .poly, the map's coordinates are: (3.2-3.3,42.2-42.3) ie. as if the .poly values are truncated to one decimal.
2. when i make the map without the .poly, the coordinates are the same as the region.
3. when i make the map with osmosis using the .poly, and the rest of the mc processing NOT using it (ie. 2 jobs), the map's coordinates are the same as the region, and the cutting seems to be correct, corresponding to the .poly.
This might suggest that osmosis uses all .poly decimals, and mc truncates the .poly coordinates to one decimal - is that correct?
If that is the case, it might be better to let mc round to one decimal: up for positive and down for negative values - the maps' size will hardly increase?

Regards

[Nop]

I just checked the code, there is no rounding of the coordinates and the poly is directly handed on to osmosis.

Do you see the rounding in the actual map data or in a bounds entry?

[ogrums]

I edited my first post beacuse of new findings, please read.

Regards

Edit: added documentation screenshots of case 1, 2, and 3:

[Nop]

Thanks for the excellent description. With the additonal data I was able to locate the bug. It was an off-by-one initialization, that was accidentially compensated when not using polygons for cutting.

As a nice side effect, I found a way to make the tile splitting calculation a little faster.

It will be fixed in the next release. I am now testing with larger maps, just to make sure...