Hi, I see that the polygons are deformed in MapSource compared to the online openstreetmap view. When I draw a polygon, I make perfect line and angles but when I see it compiled in MapSource it is not the same form. I don’t understand why. Thanks
Am 21.12.2012 23:38, schrieb --enrico:
Hi, I see that the polygons are deformed in MapSource compared to the online openstreetmap view. When I draw a polygon, I make perfect line and angles but when I see it compiled in MapSource it is not the same form. I don't understand why. Thanks This is because of Garmin-map format. Coordinates aren't as precise as OSM format.
Henning
Oh thanks! So there is really nothing to do to solve this problem? From: Henning Scholland Sent: Friday, December 21, 2012 11:39 PM To: Development list for mkgmap Subject: Re: [mkgmap-dev] Polygons deformed Am 21.12.2012 23:38, schrieb --enrico: Hi, I see that the polygons are deformed in MapSource compared to the online openstreetmap view. When I draw a polygon, I make perfect line and angles but when I see it compiled in MapSource it is not the same form. I don’t understand why. Thanks This is because of Garmin-map format. Coordinates aren't as precise as OSM format. Henning -------------------------------------------------------------------------------- _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Am 21.12.2012 23:45, schrieb --enrico:
Oh thanks! So there is really nothing to do to solve this problem? Hi, I guess mkgmap is rounding the OSM coords. Maybe if them were only inclined or only declined to next Garmin coord there could be more beautiful polygons and ways. But this is only a guess. Maybe someone else can verify this.
Henning
Is a pity that we can not solve this problem. When drawing in OSM I spend a lot of time to trace the building as closely as possible but then I can not see in MapSource. It seems strange we can not do anything ... --enrico From: Henning Scholland Sent: Saturday, December 22, 2012 12:30 AM To: Development list for mkgmap Subject: Re: [mkgmap-dev] Polygons deformed Am 21.12.2012 23:45, schrieb --enrico: Oh thanks! So there is really nothing to do to solve this problem? Hi, I guess mkgmap is rounding the OSM coords. Maybe if them were only inclined or only declined to next Garmin coord there could be more beautiful polygons and ways. But this is only a guess. Maybe someone else can verify this. Henning -------------------------------------------------------------------------------- _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
On Sat, Dec 22, 2012 at 09:47:23AM +0100, --enrico wrote:
Is a pity that we can not solve this problem. When drawing in OSM I spend a lot of time to trace the building as closely as possible but then I can not see in MapSource.
It is a limitation of the Garmin map format that is supported by mkgmap. The map resolution is something like 5 meters, depending on the latitude.
It seems strange we can not do anything ...
One thing that mkgmap could do better is to suppress bogus messages about small roundabouts 'going in wrong direction' when they have been split to multiple segments due to (bus) route relations. OsmAnd on an Android device could work for some needs. You have a variety of screen sizes, but you have to be careful about the GPS accuracy. Luckily, the Xperia Active hardware has been rather good value for money for me. Long-distance offline routing is not yet quite there and there can be some minor glitches. Best regards, Marko
Am 21.12.2012 23:39, schrieb Henning Scholland:
This is because of Garmin-map format. Coordinates aren't as precise as OSM format.
Yes, as far as I know they have a resolution of only 4 meters. Leading to the funny situation that a roundabout which is mapped precisely with 100 nodes looks ugly on Garmin compared to a circle that is mapped with only 8 nodes. I already experimented with the --reduce-point-density-polygon=NUM option but without much success. Chris
I tried with the --reduce-point-density-polygon=NUM but I don't see any difference.... What a pity this problem! --enrico -----Messaggio originale----- From: Chris66 Sent: Saturday, December 22, 2012 10:03 AM To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Polygons deformed Am 21.12.2012 23:39, schrieb Henning Scholland:
This is because of Garmin-map format. Coordinates aren't as precise as OSM format.
Yes, as far as I know they have a resolution of only 4 meters. Leading to the funny situation that a roundabout which is mapped precisely with 100 nodes looks ugly on Garmin compared to a circle that is mapped with only 8 nodes. I already experimented with the --reduce-point-density-polygon=NUM option but without much success. Chris _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Ideas from someone else? Thanks! --enrico -----Messaggio originale----- From: Chris66 Sent: Saturday, December 22, 2012 10:03 AM To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Polygons deformed Am 21.12.2012 23:39, schrieb Henning Scholland:
This is because of Garmin-map format. Coordinates aren't as precise as OSM format.
Yes, as far as I know they have a resolution of only 4 meters. Leading to the funny situation that a roundabout which is mapped precisely with 100 nodes looks ugly on Garmin compared to a circle that is mapped with only 8 nodes. I already experimented with the --reduce-point-density-polygon=NUM option but without much success. Chris _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
The problem is the Garmin-Data-Format. Garmin use only 24 Bit for longitude/latitude. This is for the highest zoom. If you reduce the zoom, then use garmin internaly only 23, 22, ... Bit. The biggest number with 24 Bit is 16.777.215. Use this for 360°. From this it follows that 360°/16.777.215 is the minimal distance. What means that for example for the equator? 360° stands for around 40.075 km circumference of the earth. The minimal distance is for a latitude of 0° around 2,4m! For higher latitude it is of course higher. I think, there is no way. 24 Bit for longitude/latitude is to less. But more Bits are more memory consumption and bigger maps. See also on my web-page "Linien- und Polygonvereinfachung" http://technik.stinnerweb.de/Gps/garmin1.html. It is in german, but the pictures are language-independed ;) Frank
Frank Stinner wrote
The problem is the Garmin-Data-Format.
Garmin use only 24 Bit for longitude/latitude. This is for the highest zoom. If you reduce the zoom, then use garmin internaly only 23, 22, ... Bit. The biggest number with 24 Bit is 16.777.215. Use this for 360°. From this it follows that 360°/16.777.215 is the minimal distance. What means that for example for the equator? 360° stands for around 40.075 km circumference of the earth. The minimal distance is for a latitude of 0° around 2,4m! For higher latitude it is of course higher.
I think, there is no way. 24 Bit for longitude/latitude is to less. But more Bits are more memory consumption and bigger maps.
See also on my web-page "Linien- und Polygonvereinfachung" http://technik.stinnerweb.de/Gps/garmin1.html. It is in german, but the pictures are language-independed ;)
I assume this problem will "disappear" when cheap hardware is able to handle more details, means, Garmin will sell new hardware with new software and new map formats or everything will be done just in time using online data. Gerd -- View this message in context: http://gis.19327.n5.nabble.com/Polygons-deformed-tp5741452p5741620.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
GerdP wrote
I assume this problem will "disappear" when cheap hardware is able to handle more details, means, Garmin will sell new hardware with new software and new map formats or everything will be done just in time using online data.
Gerd
Offtopic: The competitors are already there ... outdoors mobiles with Android. It would be a life insurance for Garmin to open their format and let the community create full featured, high quality maps. Garmin has a new CEO since a few weaks ... we will see what happens next year. Klaus -- View this message in context: http://gis.19327.n5.nabble.com/Polygons-deformed-tp5741452p5741654.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
Am 24.12.2012 10:53, schrieb Chris66:
The way would be to improve the reduce-point-density options.
Of course this would not help for buildings mapped with 4 points but could improve roundabouts and streets mapped with a high density. Chris
Hi, I think we have solved this problem at least partly during the last weeks. If you still find deformed polygons or roundabouts that cannot be explained by the rounding problems, please let me know how to reproduce the problem. Reg. roundabouts there is one additional source of problems in the remove-short-arcs function which might "move" the points of the roundabout into the direction of the connected roads. If this is the case I have an idea how to fix that. Gerd Chris66 wrote
Am 24.12.2012 10:53, schrieb Chris66:
The way would be to improve the reduce-point-density options.
Of course this would not help for buildings mapped with 4 points but could improve roundabouts and streets mapped with a high density.
Chris
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/Polygons-deformed-tp5741452p5751928.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
participants (7)
-
--enrico -
Chris66 -
Frank Stinner -
GerdP -
Henning Scholland -
Marko Mäkelä -
toc-rox