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

Wed May 5 08:27:25 BST 2021

labels as in just names, or highway labels? In that case for maps without
highway labels there could be more merging... And I don't think
housenumbers should make any difference for level 1 and onwards...

On Wed, 5 May 2021 at 15:13, Gerd Petermann <gpetermann_muenchen at hotmail.com>
wrote:

> Hi Felix,
>
> I already wrote it. I think NET points to levels > 0 to allow showing more
> labels, possibly also house numbers. I really don't think that data at
> levels > 0 is used for routing, but who knows what Garmin software does
> with unexpected data in NET?
>
> Gerd
>
> ________________________________________
> Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag von
> Felix Hartmann <extremecarver at gmail.com>
> Gesendet: Mittwoch, 5. Mai 2021 08:42
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] new branch low-res-opt to test improvements for
>      filters
>
> Hi Gerd,
> why does a road have pointers to lines in any level except 0? Is there
> really any routing in levels>0 ?
> As for rivers - yes they will show wrong direction than in gpsmapedit, but
> who cares? If the map is shown correctly in garmin tools, that should be
> enough. If you need the right direction then add the exception as for other
> lines that should not direction reversed. I always thought only level 0 is
> responsible for routing - whatever is in higher levels only matters for
> visual purposes.
>
> 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<mailto: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
>
> ________________________________________
> Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann <
> extremecarver at gmail.com<mailto:extremecarver at gmail.com>>
> Gesendet: Mittwoch, 5. Mai 2021 07:36
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] new branch low-res-opt to test improvements for
>      filters
>
> well a waterway can be merged if it's displayed without arrows so it
> should not have special handling.
> A cliff cannot be merged, because it should have a direction (well yes
> problem with basecamp vs gps device being opposite, but that's another
> problem maybe solved one day by garmin).
> my routes cannot be merged because they would overlap otherwise more often
>
> and so on.
> it's complicated and mainly depends on the typfile. Even oneway ways can
> be merged from level 1 onwards, if not direction dependant in the typfile.
>
>
> The reason I proposed a separate file, is that maybe types like a route or
> waterway you will have 10-20 lines in your lines file (e.g. depending on
> width or importance you show something earlier, but you still use the same
> type). Yes possible also in lines file itself, just for some styles it
> would be much cleaner in a separate file.
>
>
> And I'm not sure how much saving potential there is for roads, but merging
> a second time for level 1 until overview map may make quite a big change
> (because of oneway) and not only merge for level 0.
>
> On Wed, 5 May 2021 at 13:14, Gerd Petermann <
> gpetermann_muenchen at hotmail.com<mailto:gpetermann_muenchen at hotmail.com
> ><mailto:gpetermann_muenchen at hotmail.com<mailto:
> gpetermann_muenchen at hotmail.com>>> wrote:
> Hi Felix,
>
> yes, I have similar results.
> I am playing with an implementation that first only merges lines in the
> given direction and then tries again to merge with reversed order, but only
> if the way has no specific direction. The img format has a flag for "has a
> direction", and another one for "is oneway".
> With the current code you can only use the oneway=* tag to tell mkgmap
> that a way has a direction.
> It turned out that it looks wrong to merge waterways with a direction, so
> I added
> (waterway=river | waterway=stream | waterway=rapids | waterway=waterfall)
> {add oneway=yes}
>
> I think a new tag mkgmap:has-direction=1" would be the better alternative.
> A list of types would be another alternative, but I think the style is the
> right place to do that (and much easier to implement and document)
>
> Roads are handled earlier by the RoadMerger, and further merging is only
> possible in the overview map where there is no NET file so far.
>
> Now, most of the ways which are merged in reversed order are boundaries.
> Probably because we have incomplete type=boundary relations and thus the
> members of those relations are not joined to single closed ways. Looking at
> this now, maybe it is better to use the joined way instead of the fragments.
>
> Gerd
>
> ________________________________________
> Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk><mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk>>> im Auftrag von Felix Hartmann <
> extremecarver at gmail.com<mailto:extremecarver at gmail.com><mailto:
> extremecarver at gmail.com<mailto:extremecarver at gmail.com>>>
> Gesendet: Mittwoch, 5. Mai 2021 03:47
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] new branch low-res-opt to test improvements for
>      filters
>
> oh sorry, no I got confused. We don't need that difference based on level.
> It's one list where we add all types that in the typfile lead to being
> impossible to change direction and then of course any routable line can be
> merged also at level 0 if it is not on that list and has no oneway
> attribute. For level 1 and higher it is only about the list and those types
> which could not be merged because of oneway attribute can now also be
> merged.
>
> On Wed, 5 May 2021 at 09:42, Felix Hartmann <extremecarver at gmail.com
> <mailto:extremecarver at gmail.com><mailto:extremecarver at gmail.com<mailto:
> extremecarver at gmail.com>><mailto:extremecarver at gmail.com<mailto:
> extremecarver at gmail.com><mailto:extremecarver at gmail.com<mailto:
> extremecarver at gmail.com>>>> wrote:
> I think the simplify 4 patch had some more improvements for contourlines -
> but then I played around all the time with the DP values so it's hard to
> compare. I do know that simplify v4  versus 3 back then was an improvement.
> I think merging lines of different directions would be good too - with the
> caveat that we would need an additional instruction in the lines style-file
> to tell for lines not to merge (maybe make this a list - because then it's
> not needed each occurrence in the lines file, but once per type. I feel
> this is only important for any type that is either off center (e.g. I have
> MTB routes on the right side of the center line, hiking routes on the left
> - so you can see both if on the same way) or that have an arrow or similar
> in the typ-file (i.e. I have arrows on my rivers so you can see the
> direction of water flow). Oh and not sure if this is would be merged also
> at level 0 or only >0. That would make a big difference in how many line
> types I put on that list. I mean there are many types also at level 0 where
> I don't care about the direction. Of course any line with oneway that is
> routable could not be merged too. On the other hand even quite a few
> routable lines could be merged - but not a
>  ll.
> If this also applies to level 0, then that file needs to have one command
> for level 0, and one command for level 1 and higher. At level 1 and onwards
> it only depends on the typfile if merging is possible or not. At level 0 it
> depends on both typfile and oneway attribute.
>
> On Mon, 3 May 2021 at 23:28, Gerd Petermann <
> GPetermann_muenchen at hotmail.com<mailto:GPetermann_muenchen at hotmail.com
> ><mailto:GPetermann_muenchen at hotmail.com<mailto:
> GPetermann_muenchen at hotmail.com>><mailto:GPetermann_muenchen at hotmail.com
> <mailto:GPetermann_muenchen at hotmail.com><mailto:
> GPetermann_muenchen at hotmail.com<mailto:GPetermann_muenchen at hotmail.com>>>>
> wrote:
> Hi all,
>
> as a result of the thread about raster problems I've started this new
> branch.
>
> First commit implements experimental options to specify values for
> --reducePointError and --reducePointErrorPolygon for each resolution
> Options are --simplify-filter-line-errors as replacement for
> --reducePointError and --simplify-filter-polygon-errors as replacement for
> --reducePointErrorPolygon.
> If --simplify-filter-line-errors is given and
> ----simplify-filter-polygon-errors is not given the values for lines are
> also used for polygons.
> Meaning is similar to the --polygon-size-limits option, values are given
> in pairs <resolution,reduce-value>
> Note that in resolution 24 the filter is not used.
> Sample usage:
> --x-simplify-filter-line-errors=23:1.3,22:2.6,20:4,18:6
> --x-simplify-filter-polygon-errors=23:1.3,22:2.6,20:4
> The old options are still supported, --reducePointErrorPolygon=1.3 is
> treated like --x-simplify-filter-line-errors=23:1.3
>
> If none of the options is used the default is 2.6 for all resolutions.
>
> There are a few more things to change:
> - simplify4.patch with special code to improve rendering of contour lines
> - more-merge.patch to allow merging of roads at level > 0
> - Line merger could merge more lines if direction of the lines doesn't
> matter
> - maybe I find a way to merge dual-carriage ways into one line (again, if
> direction doesn't matter)
> - the --housenumber option should probably not assign numbers to trunk
> roads (similar to motorways), this can add lables to these roads and thus
> prohibit merging.
>
> None of these changes should change routing results. They can reduce img
> size and improve rendering.
>
> Gerd
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk<mailto:mkgmap-dev at lists.mkgmap.org.uk
> ><mailto:mkgmap-dev at lists.mkgmap.org.uk<mailto:
> mkgmap-dev at lists.mkgmap.org.uk>><mailto:mkgmap-dev at lists.mkgmap.org.uk
> <mailto:mkgmap-dev at lists.mkgmap.org.uk><mailto:
> mkgmap-dev at lists.mkgmap.org.uk<mailto: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
>
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk<mailto:mkgmap-dev at lists.mkgmap.org.uk
> ><mailto:mkgmap-dev at lists.mkgmap.org.uk<mailto:
> mkgmap-dev at lists.mkgmap.org.uk>>
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
>
> --
> Felix Hartman - Openmtbmap.org & VeloMap.org
>
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk<mailto:mkgmap-dev at lists.mkgmap.org.uk>
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
>
> --
> Felix Hartman - Openmtbmap.org & VeloMap.org
>
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20210505/e483e71d/attachment-0001.html>