<div dir="ltr">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...</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 5 May 2021 at 15:32, Felix Hartmann <<a href="mailto:extremecarver@gmail.com">extremecarver@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">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.<div><br></div><div>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.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 5 May 2021 at 15:27, Thomas Morgenstern <<a href="mailto:webmaster@img2ms.de" target="_blank">webmaster@img2ms.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  

    
  
  <div bgcolor="#FFFFFF">
    <div dir="ltr">Hi all, I see this completly different :  many people
      use osm data for routing.   Routing is the main purpose  for using
      OSM. If routing [ <i>quote] : </i><i> it will look a bit strange
        [end quote] </i>is not akzeptable.<br>
      <br>
      Thomas<br>
      <br>
      <br>
      <div>Quote :.............<br>
      </div>
      <div>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.
        ......</div>
    </div>
    <br>
    <div dir="ltr" class="gmail_attr">On Wed, 5 May 2021 at 14:29, Gerd
      Petermann <<a href="mailto:gpetermann_muenchen@hotmail.com" target="_blank">gpetermann_muenchen@hotmail.com</a>>
      wrote:<br>
    </div>
    Hi Felix,<br>
    <br>
    I don't think that it only depends on the typ file. Programs like
    GpsMapEdit also show wrong merges.<br>
    <br>
    Reg. roads: Seems RoadMerger also doesn't reverse points, I didn't
    notice that before. So, I have two methods to improve.<br>
    It's quite difficult to understand the effects because we<br>
    - merge roads with equal attributes<br>
    - 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)<br>
    - possibly merge again at levels > 0<br>
    <br>
    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.<br>
    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.<br>
    Probably it doesn't matter much when RoadMerger is allowed to
    reverse so that we have fewer parts which could be merged later.<br>
    <br>
    Gerd
  </div>

_______________________________________________<br>
mkgmap-dev mailing list<br>
<a href="mailto:mkgmap-dev@lists.mkgmap.org.uk" target="_blank">mkgmap-dev@lists.mkgmap.org.uk</a><br>
<a href="https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev" rel="noreferrer" target="_blank">https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev</a></blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Felix Hartman - Openmtbmap.org & VeloMap.org<br></div><br></div></div></div></div></div></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Felix Hartman - Openmtbmap.org & VeloMap.org<br></div><br></div></div></div></div></div></div>