Hi, a few weeks ago I suggested that we might need higher precision in the Coord class. Attached patch is a quick hack to implement this. If I got it right, this may allow to remove a lot of code that tries to correct what the rounding had done wrong. For the beginning, I've used the precise values only for bearing calculations, as I think that this is most important. high_precision_coord_v1.patch <http://gis.19327.n5.nabble.com/file/n5783533/high_precision_coord_v1.patch> Please let me know what you think about it. Gerd -- View this message in context: http://gis.19327.n5.nabble.com/Patch-v1-avoid-wrong-bearing-results-tp578353... Sent from the Mkgmap Development mailing list archive at Nabble.com.
On Thu, Oct 31, 2013 at 10:08:53AM -0700, GerdP wrote:
a few weeks ago I suggested that we might need higher precision in the Coord class.
Attached patch is a quick hack to implement this. If I got it right, this may allow to remove a lot of code that tries to correct what the rounding had done wrong. For the beginning, I've used the precise values only for bearing calculations, as I think that this is most important.
high_precision_coord_v1.patch <http://gis.19327.n5.nabble.com/file/n5783533/high_precision_coord_v1.patch>
Please let me know what you think about it.
This sounds interesting. I tried it out on finland.osm.pbf, wondering if it would make some of the bogus warnings for anti-islands go away. (There are some very tiny islets or rocks mapped as natural=coastline.) I guess, it is to be expected that your patch does not yet fix bogus warnings about the direction of hyper-precisely mapped roundabouts or tiny coastline polygons. Here is an example that I got with your patch: 2013/10/31 21:16:32 WARNING (SeaGenerator): 63240002.osm.pbf: Converting anti-island starting at http://www.openstreetmap.org/?mlat=60.21780&mlon=25.30937&zoom=17 into an island as it is surrounded by water This is http://www.openstreetmap.org/browse/way/241289746, a tiny islet, properly mapped in counterclockwise direction. For some reason, current svn head (r2795) with your patch is producing more error messages than the revision I used earlier (I guess r2640). With the old mkgmap, I got 545041 bytes of log, and with the patched r2795, I got 774890 bytes, for the same input. The map sizes grew too: Length Method Size Cmpr Date Time CRC-32 Name 142065664 Defl:X 113283124 20% 2013-10-31 05:23 05eede3d gmapsupp.img 143736832 Defl:X 114490132 20% 2013-10-31 05:23 662f2ea9 gmapsupp.img (The timestamp is that of the finland.osm.pbf file.) Best regards, Marko
Hi Marko, the patch (this v1) is only meant to solve routing problems caused by rounding I don't think that it has an influence on SeaGenerator. It is possible that it increases NOD size a little bit. Do you have a reason for not using precompiled sea? Ciao, Gerd
Date: Thu, 31 Oct 2013 21:36:54 +0200 From: marko.makela@iki.fi To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] [Patch v1] avoid wrong bearing results
On Thu, Oct 31, 2013 at 10:08:53AM -0700, GerdP wrote:
a few weeks ago I suggested that we might need higher precision in the Coord class.
Attached patch is a quick hack to implement this. If I got it right, this may allow to remove a lot of code that tries to correct what the rounding had done wrong. For the beginning, I've used the precise values only for bearing calculations, as I think that this is most important.
high_precision_coord_v1.patch <http://gis.19327.n5.nabble.com/file/n5783533/high_precision_coord_v1.patch>
Please let me know what you think about it.
This sounds interesting. I tried it out on finland.osm.pbf, wondering if it would make some of the bogus warnings for anti-islands go away. (There are some very tiny islets or rocks mapped as natural=coastline.)
I guess, it is to be expected that your patch does not yet fix bogus warnings about the direction of hyper-precisely mapped roundabouts or tiny coastline polygons. Here is an example that I got with your patch:
2013/10/31 21:16:32 WARNING (SeaGenerator): 63240002.osm.pbf: Converting anti-island starting at http://www.openstreetmap.org/?mlat=60.21780&mlon=25.30937&zoom=17 into an island as it is surrounded by water
This is http://www.openstreetmap.org/browse/way/241289746, a tiny islet, properly mapped in counterclockwise direction.
For some reason, current svn head (r2795) with your patch is producing more error messages than the revision I used earlier (I guess r2640). With the old mkgmap, I got 545041 bytes of log, and with the patched r2795, I got 774890 bytes, for the same input. The map sizes grew too:
Length Method Size Cmpr Date Time CRC-32 Name 142065664 Defl:X 113283124 20% 2013-10-31 05:23 05eede3d gmapsupp.img 143736832 Defl:X 114490132 20% 2013-10-31 05:23 662f2ea9 gmapsupp.img
(The timestamp is that of the finland.osm.pbf file.)
Best regards,
Marko _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
On Thu, Oct 31, 2013 at 10:44:31PM +0100, Gerd Petermann wrote:
the patch (this v1) is only meant to solve routing problems caused by rounding I don't think that it has an influence on SeaGenerator.
Right, I was too optimistic, hoping that this would fix the bogus warnings in SeaGenerator too. The patch (or some other change since r2795) did make 2 of 4 warnings for roundabout flare roads go away. Only the following remained: 2013/10/31 21:17:17 WARNING (StyledConverter): 63240002.osm.pbf: Roundabout segment 35062431 direction looks wrong (see http://www.openstreetmap.org/?mlat=60.23825&mlon=24.88777&zoom=17) 2013/10/31 21:17:18 WARNING (StyledConverter): 63240002.osm.pbf: Roundabout segment 34151581 direction looks wrong (see http://www.openstreetmap.org/?mlat=60.23242&mlon=24.95879&zoom=17) 2013/10/31 21:17:37 WARNING (RouteNode): 63240005.osm.pbf: Outgoing roundabout flare road (4;9;13;23 Vaajakoskentie, http://www.openstreetmap.org/browse/way/221616945) points in wrong direction? http://www.openstreetmap.org/?mlat=62.24637&mlon=25.87302&zoom=17 Both roundabout segments are in micro-mapped roundabouts that have been split because of route relations. I reverted your patch and reran with today's dump. I got again the usual 5 roundabout warnings (2 more about flare roads) than the above. So, your patch is making a positive difference there.
Do you have a reason for not using precompiled sea?
Yes. I mainly use mkgmap as a validator, and I am routinely fixing errors in finland.osm.pbf. The sea polygons are not severely broken that often, it is usually just anti-islands. Only about once per month I have to fire up JOSM with an Osmosis-made extract of natural=coastline to see what is wrong. Best regards, Marko
Hi Marko,
the patch (this v1) is only meant to solve routing problems caused by rounding I don't think that it has an influence on SeaGenerator.
Right, I was too optimistic, hoping that this would fix the bogus warnings in SeaGenerator too.
Maybe it is possible to use the higher precision for this as well. I assume we just have to use it when converting to java areas in Java2DConverter.
The patch (or some other change since r2795) did make 2 of 4 warnings for roundabout flare roads go away. Only the following remained:
2013/10/31 21:17:17 WARNING (StyledConverter): 63240002.osm.pbf: Roundabout segment 35062431 direction looks wrong (see http://www.openstreetmap.org/?mlat=60.23825&mlon=24.88777&zoom=17) 2013/10/31 21:17:18 WARNING (StyledConverter): 63240002.osm.pbf: Roundabout segment 34151581 direction looks wrong (see http://www.openstreetmap.org/?mlat=60.23242&mlon=24.95879&zoom=17) 2013/10/31 21:17:37 WARNING (RouteNode): 63240005.osm.pbf: Outgoing roundabout flare road (4;9;13;23 Vaajakoskentie, http://www.openstreetmap.org/browse/way/221616945) points in wrong direction? http://www.openstreetmap.org/?mlat=62.24637&mlon=25.87302&zoom=17
Both roundabout segments are in micro-mapped roundabouts that have been split because of route relations.
I reverted your patch and reran with today's dump. I got again the usual 5 roundabout warnings (2 more about flare roads) than the above. So, your patch is making a positive difference there.
OK, that's what I expected :-) As I said, the patch was a quick hack, I just wanted to demonstrate that we only have to change a few lines to store the higher precision, and it will not cost more memory.
Do you have a reason for not using precompiled sea?
Yes. I mainly use mkgmap as a validator, and I am routinely fixing errors in finland.osm.pbf. The sea polygons are not severely broken that often, it is usually just anti-islands. Only about once per month I have to fire up JOSM with an Osmosis-made extract of natural=coastline to see what is wrong.
OK, I see. I'll try with the same data to check what can be changed. Gerd
Hi Marko, I think the SeaGenerator might be improved by using higher precision coordinates. But since the precompiled sea option is available I will not put any more effort into the "old" algorithms. WanMil
On Thu, Oct 31, 2013 at 10:44:31PM +0100, Gerd Petermann wrote:
the patch (this v1) is only meant to solve routing problems caused by rounding I don't think that it has an influence on SeaGenerator.
Right, I was too optimistic, hoping that this would fix the bogus warnings in SeaGenerator too.
The patch (or some other change since r2795) did make 2 of 4 warnings for roundabout flare roads go away. Only the following remained:
2013/10/31 21:17:17 WARNING (StyledConverter): 63240002.osm.pbf: Roundabout segment 35062431 direction looks wrong (see http://www.openstreetmap.org/?mlat=60.23825&mlon=24.88777&zoom=17) 2013/10/31 21:17:18 WARNING (StyledConverter): 63240002.osm.pbf: Roundabout segment 34151581 direction looks wrong (see http://www.openstreetmap.org/?mlat=60.23242&mlon=24.95879&zoom=17) 2013/10/31 21:17:37 WARNING (RouteNode): 63240005.osm.pbf: Outgoing roundabout flare road (4;9;13;23 Vaajakoskentie, http://www.openstreetmap.org/browse/way/221616945) points in wrong direction? http://www.openstreetmap.org/?mlat=62.24637&mlon=25.87302&zoom=17
Both roundabout segments are in micro-mapped roundabouts that have been split because of route relations.
I reverted your patch and reran with today's dump. I got again the usual 5 roundabout warnings (2 more about flare roads) than the above. So, your patch is making a positive difference there.
Do you have a reason for not using precompiled sea?
Yes. I mainly use mkgmap as a validator, and I am routinely fixing errors in finland.osm.pbf. The sea polygons are not severely broken that often, it is usually just anti-islands. Only about once per month I have to fire up JOSM with an Osmosis-made extract of natural=coastline to see what is wrong.
Best regards,
Marko _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd, well done! I like the way that the higher precision can be used step by step and we don't have to change the whole source code at once! Does the change require more memory? I have seen two new byte fields in the Coord class. WanMil
Hi,
a few weeks ago I suggested that we might need higher precision in the Coord class.
Attached patch is a quick hack to implement this. If I got it right, this may allow to remove a lot of code that tries to correct what the rounding had done wrong. For the beginning, I've used the precise values only for bearing calculations, as I think that this is most important.
high_precision_coord_v1.patch <http://gis.19327.n5.nabble.com/file/n5783533/high_precision_coord_v1.patch>
Please let me know what you think about it.
Gerd
Hi WanMil,
well done! I like the way that the higher precision can be used step by step and we don't have to change the whole source code at once!
yes, that's why I liked it so much that I posted the quick hack. The next step might be to use it in Java2DConverter and routines like Way.clockwise(). It might also be used to beautify roundabouts and other zig-zagging caused by rounding errors.
Does the change require more memory? I have seen two new byte fields in the Coord class.
no, it uses two spare bytes (a Coord instance allocates 16 bytes (8 byte alignment) with the patch 12 bytes are used, still leaving 4 spare bytes) Gerd
participants (4)
-
Gerd Petermann -
GerdP
-
Marko Mäkelä -
WanMil