Re: [mkgmap-dev] new branch low-res-opt to test improvements for filters
Hi all, I see this completly different : many people use osm data for routing. Routing is the main purpose for using OSM. If routing [ /quote] : //it will look a bit strange [end quote] /is not akzeptable. Thomas Quote :............. So yes with very high DP values and lots of simplification if you plan a car route over highways, at some point it will look a bit strange. But again, very few people use Garmin maps for car routing nowadays, and even less car routing based on OSM data. ...... On Wed, 5 May 2021 at 14:29, Gerd Petermann <gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com>> wrote: Hi Felix, I don't think that it only depends on the typ file. Programs like GpsMapEdit also show wrong merges. Reg. roads: Seems RoadMerger also doesn't reverse points, I didn't notice that before. So, I have two methods to improve. It's quite difficult to understand the effects because we - merge roads with equal attributes - possibly split those roads again to avoid loops or too long roads or too complex roads (too many connections) or other limits in IMG format (this is needed for routable maps, maybe not for others) - possibly merge again at levels > 0 I have to think about this again. Maybe there is no problem with the NET file changes when this last step is done. The NET file contains "pointers" to the RGN file for each level in which the road is rendered. So, if a road is rendered at level 1 the data in NET allows to show all the road labels. Maybe that's all and there is no further effect (esp. not on routing), but maybe the info is also used when you create route in Basecamp. I guess it's not. I have no idea what Garmin software does when a road has pointers to lines at levels 0, 1, and 3 but not at level 2. I found no such case in Garmin demo maps. I think that could happen when I don't add code to prevent it. Probably it doesn't matter much when RoadMerger is allowed to reverse so that we have fewer parts which could be merged later. Gerd
Really, routing over long distances on highways? I haven"t met people using a Garmin GPS device routing via highways - however many who use it for recreational purposes - so routing over short distances. Anyhow if you use a lower DP value no problem there. It's mainly if you zoom out to overview map resolution at 18, 17 or wherever that starts. So far mkgmap maps were unusable on devices for 17 or lower due to being very slow. I'm not sure how much of this was too much data in those tiles, and how much that the device has to look up too many tiles. That's what the device is using the basemap for, and Basecamp using the overview map for. So if you zoom out that far - no problems if the route doesn't fully follow the underlying map. It's the same for Garmin city navigator maps. On Wed, 5 May 2021 at 15:27, Thomas Morgenstern <webmaster@img2ms.de> wrote:
Hi all, I see this completly different : many people use osm data for routing. Routing is the main purpose for using OSM. If routing [ *quote] : ** it will look a bit strange [end quote] *is not akzeptable.
Thomas
Quote :............. So yes with very high DP values and lots of simplification if you plan a car route over highways, at some point it will look a bit strange. But again, very few people use Garmin maps for car routing nowadays, and even less car routing based on OSM data. ......
On Wed, 5 May 2021 at 14:29, Gerd Petermann < gpetermann_muenchen@hotmail.com> wrote: Hi Felix,
I don't think that it only depends on the typ file. Programs like GpsMapEdit also show wrong merges.
Reg. roads: Seems RoadMerger also doesn't reverse points, I didn't notice that before. So, I have two methods to improve. It's quite difficult to understand the effects because we - merge roads with equal attributes - possibly split those roads again to avoid loops or too long roads or too complex roads (too many connections) or other limits in IMG format (this is needed for routable maps, maybe not for others) - possibly merge again at levels > 0
I have to think about this again. Maybe there is no problem with the NET file changes when this last step is done. The NET file contains "pointers" to the RGN file for each level in which the road is rendered. So, if a road is rendered at level 1 the data in NET allows to show all the road labels. Maybe that's all and there is no further effect (esp. not on routing), but maybe the info is also used when you create route in Basecamp. I guess it's not. I have no idea what Garmin software does when a road has pointers to lines at levels 0, 1, and 3 but not at level 2. I found no such case in Garmin demo maps. I think that could happen when I don't add code to prevent it. Probably it doesn't matter much when RoadMerger is allowed to reverse so that we have fewer parts which could be merged later.
Gerd _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
oh yeah - and as long as you do not crash the size limit on the overview map - just use a lower DP value then. Removing of the zig zags actually enables you to use a lower DP value in the overview map - hence matching the route actually better than before. Overview map is always pretty fast. Just watch out - if you put too much into it, then compile Asia continent map or Europe continent map - you either adapt your DP values for them, or adapt your style... On Wed, 5 May 2021 at 15:32, Felix Hartmann <extremecarver@gmail.com> wrote:
Really, routing over long distances on highways? I haven"t met people using a Garmin GPS device routing via highways - however many who use it for recreational purposes - so routing over short distances.
Anyhow if you use a lower DP value no problem there. It's mainly if you zoom out to overview map resolution at 18, 17 or wherever that starts. So far mkgmap maps were unusable on devices for 17 or lower due to being very slow. I'm not sure how much of this was too much data in those tiles, and how much that the device has to look up too many tiles. That's what the device is using the basemap for, and Basecamp using the overview map for. So if you zoom out that far - no problems if the route doesn't fully follow the underlying map. It's the same for Garmin city navigator maps.
On Wed, 5 May 2021 at 15:27, Thomas Morgenstern <webmaster@img2ms.de> wrote:
Hi all, I see this completly different : many people use osm data for routing. Routing is the main purpose for using OSM. If routing [ *quote] : ** it will look a bit strange [end quote] *is not akzeptable.
Thomas
Quote :............. So yes with very high DP values and lots of simplification if you plan a car route over highways, at some point it will look a bit strange. But again, very few people use Garmin maps for car routing nowadays, and even less car routing based on OSM data. ......
On Wed, 5 May 2021 at 14:29, Gerd Petermann < gpetermann_muenchen@hotmail.com> wrote: Hi Felix,
I don't think that it only depends on the typ file. Programs like GpsMapEdit also show wrong merges.
Reg. roads: Seems RoadMerger also doesn't reverse points, I didn't notice that before. So, I have two methods to improve. It's quite difficult to understand the effects because we - merge roads with equal attributes - possibly split those roads again to avoid loops or too long roads or too complex roads (too many connections) or other limits in IMG format (this is needed for routable maps, maybe not for others) - possibly merge again at levels > 0
I have to think about this again. Maybe there is no problem with the NET file changes when this last step is done. The NET file contains "pointers" to the RGN file for each level in which the road is rendered. So, if a road is rendered at level 1 the data in NET allows to show all the road labels. Maybe that's all and there is no further effect (esp. not on routing), but maybe the info is also used when you create route in Basecamp. I guess it's not. I have no idea what Garmin software does when a road has pointers to lines at levels 0, 1, and 3 but not at level 2. I found no such case in Garmin demo maps. I think that could happen when I don't add code to prevent it. Probably it doesn't matter much when RoadMerger is allowed to reverse so that we have fewer parts which could be merged later.
Gerd _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
-- Felix Hartman - Openmtbmap.org & VeloMap.org
Hi. Sorry for getting into the discussion. Routing over long distances is important, also via highways. There can be multiple nearby exists along the way that one does not know by heart and does not want to miss. Quite often one (at least i) does not want to fiddle around with device while driving, instead simply start the route in the beginning even if a large portion of the travel is fairly known. Regards Karl On onsdag 5 maj 2021 kl. 09:32:52 CEST Felix Hartmann wrote:
Really, routing over long distances on highways? I haven"t met people using a Garmin GPS device routing via highways - however many who use it for recreational purposes - so routing over short distances.
Anyhow if you use a lower DP value no problem there. It's mainly if you zoom out to overview map resolution at 18, 17 or wherever that starts. So far mkgmap maps were unusable on devices for 17 or lower due to being very slow. I'm not sure how much of this was too much data in those tiles, and how much that the device has to look up too many tiles. That's what the device is using the basemap for, and Basecamp using the overview map for. So if you zoom out that far - no problems if the route doesn't fully follow the underlying map. It's the same for Garmin city navigator maps.
On Wed, 5 May 2021 at 15:27, Thomas Morgenstern <webmaster@img2ms.de> wrote:
Hi all, I see this completly different : many people use osm data for routing. Routing is the main purpose for using OSM. If routing [ *quote]
: ** it will look a bit strange [end quote] *is not akzeptable.
Thomas
Quote :............. So yes with very high DP values and lots of simplification if you plan a car route over highways, at some point it will look a bit strange. But again, very few people use Garmin maps for car routing nowadays, and even less car routing based on OSM data. ......
On Wed, 5 May 2021 at 14:29, Gerd Petermann < gpetermann_muenchen@hotmail.com> wrote: Hi Felix,
I don't think that it only depends on the typ file. Programs like GpsMapEdit also show wrong merges.
Reg. roads: Seems RoadMerger also doesn't reverse points, I didn't notice that before. So, I have two methods to improve. It's quite difficult to understand the effects because we - merge roads with equal attributes - possibly split those roads again to avoid loops or too long roads or too complex roads (too many connections) or other limits in IMG format (this is needed for routable maps, maybe not for others) - possibly merge again at levels > 0
I have to think about this again. Maybe there is no problem with the NET file changes when this last step is done. The NET file contains "pointers" to the RGN file for each level in which the road is rendered. So, if a road is rendered at level 1 the data in NET allows to show all the road labels. Maybe that's all and there is no further effect (esp. not on routing), but maybe the info is also used when you create route in Basecamp. I guess it's not. I have no idea what Garmin software does when a road has pointers to lines at levels 0, 1, and 3 but not at level 2. I found no such case in Garmin demo maps. I think that could happen when I don't add code to prevent it. Probably it doesn't matter much when RoadMerger is allowed to reverse so that we have fewer parts which could be merged later.
Gerd _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Karl, But even then you will never use the overview map. What resolution are you actually using on your device if routing on a highway? I guess 19 or 20... The thing is simply with high DP filter value that you can see the highway pretty straight, but as the route itself is not simplifed that much in Basecamp. The route will not be 1:1 visually of the map. But still very easy to see the the underlying highway. if you plan a route from Berlin to Mardrid, then zoom out and see the whole route - then it's not so beautiful anymore. But can any mkgmap created map actually route from Berlin to Madrid without via points? It's a long time that I looked at mgkmap created maps for car routing and some years ago this was not possible. On Wed, 5 May 2021 at 15:48, 7770 <7770@foskan.eu> wrote:
Hi. Sorry for getting into the discussion. Routing over long distances is important, also via highways. There can be multiple nearby exists along the way that one does not know by heart and does not want to miss. Quite often one (at least i) does not want to fiddle around with device while driving, instead simply start the route in the beginning even if a large portion of the travel is fairly known.
Regards Karl
On onsdag 5 maj 2021 kl. 09:32:52 CEST Felix Hartmann wrote:
Really, routing over long distances on highways? I haven"t met people using a Garmin GPS device routing via highways - however many who use it for recreational purposes - so routing over short distances.
Anyhow if you use a lower DP value no problem there. It's mainly if you zoom out to overview map resolution at 18, 17 or wherever that starts. So far mkgmap maps were unusable on devices for 17 or lower due to being very slow. I'm not sure how much of this was too much data in those tiles, and how much that the device has to look up too many tiles. That's what the device is using the basemap for, and Basecamp using the overview map for. So if you zoom out that far - no problems if the route doesn't fully follow the underlying map. It's the same for Garmin city navigator maps.
On Wed, 5 May 2021 at 15:27, Thomas Morgenstern <webmaster@img2ms.de> wrote:
Hi all, I see this completly different : many people use osm data for routing. Routing is the main purpose for using OSM. If routing [ *quote]
: ** it will look a bit strange [end quote] *is not akzeptable.
Thomas
Quote :............. So yes with very high DP values and lots of simplification if you plan a car route over highways, at some point it will look a bit strange. But again, very few people use Garmin maps for car routing nowadays, and even less car routing based on OSM data. ......
On Wed, 5 May 2021 at 14:29, Gerd Petermann < gpetermann_muenchen@hotmail.com> wrote: Hi Felix,
I don't think that it only depends on the typ file. Programs like GpsMapEdit also show wrong merges.
Reg. roads: Seems RoadMerger also doesn't reverse points, I didn't notice that before. So, I have two methods to improve. It's quite difficult to understand the effects because we - merge roads with equal attributes - possibly split those roads again to avoid loops or too long roads or too complex roads (too many connections) or other limits in IMG format (this is needed for routable maps, maybe not for others) - possibly merge again at levels > 0
I have to think about this again. Maybe there is no problem with the NET file changes when this last step is done. The NET file contains "pointers" to the RGN file for each level in which the road is rendered. So, if a road is rendered at level 1 the data in NET allows to show all the road labels. Maybe that's all and there is no further effect (esp. not on routing), but maybe the info is also used when you create route in Basecamp. I guess it's not. I have no idea what Garmin software does when a road has pointers to lines at levels 0, 1, and 3 but not at level 2. I found no such case in Garmin demo maps. I think that could happen when I don't add code to prevent it. Probably it doesn't matter much when RoadMerger is allowed to reverse so that we have fewer parts which could be merged later.
Gerd _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
On Wed, May 05, 2021 at 03:32:52PM +0800, Felix Hartmann wrote:
Really, routing over long distances on highways? I haven"t met people using a Garmin GPS device routing via highways - however many who use it for recreational purposes - so routing over short distances.
Well, I am another one who regularly uses mkgmaps on my Garmin etrex for distance routing. ael
Hi all, I don't use mkgmap for long distance routing but I've created this branch with the goal that rendering is improved and routing is NOT changed. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von ael <witwall3@disroot.org> Gesendet: Mittwoch, 5. Mai 2021 13:18 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] new branch low-res-opt to test improvements for filters On Wed, May 05, 2021 at 03:32:52PM +0800, Felix Hartmann wrote:
Really, routing over long distances on highways? I haven"t met people using a Garmin GPS device routing via highways - however many who use it for recreational purposes - so routing over short distances.
Well, I am another one who regularly uses mkgmaps on my Garmin etrex for distance routing. ael _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
2 megameter is a short trip (about 1250 miles)? I made this trip three times in this last year. This is almost exclusively Interstate usage (think German Autobahn). On 05-May-21 03:32, Felix Hartmann wrote:
Really, routing over long distances on highways? I haven"t met people using a Garmin GPS device routing via highways - however many who use it for recreational purposes - so routing over short distances.
participants (7)
-
7770 -
ael -
Dave -
Felix Hartmann -
Gerd Petermann -
Randolph J. Herber -
Thomas Morgenstern