[mkgmap-dev] new branch low-res-opt to test improvements for filters

Wed May 5 08:37:40 BST 2021

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 at 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 at 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 at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20210505/586c736c/attachment-0001.html>