.poly file - coordinate accuracy

Diskussionen zu dem Werkzeug hinter der Karte und für eigene Garminkarten
Antworten
ogrums
Beiträge: 13
Registriert: 17.04.2021, 17:40

.poly file - coordinate accuracy

Beitrag von 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
Zuletzt geändert von ogrums am 25.08.2021, 09:42, insgesamt 1-mal geändert.
Benutzeravatar
Nop
Site Admin
Beiträge: 567
Registriert: 10.01.2019, 20:46

Re: cutting with osmosis and .poly file

Beitrag von 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
Beiträge: 13
Registriert: 17.04.2021, 17:40

Re: .poly file - coordinate accuracy

Beitrag von ogrums »

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

Regards

Edit: added documentation screenshots of case 1, 2, and 3:
123.png
Benutzeravatar
Nop
Site Admin
Beiträge: 567
Registriert: 10.01.2019, 20:46

Re: .poly file - coordinate accuracy

Beitrag von 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...
Antworten