[mkgmap-dev] Open question reg. new nearby-poi options

Thu May 7 11:47:27 BST 2020

Hi Eric,

Maybe the subject was misleading.
Can you give an example that shows an influence of the --nearby-poi-* options on routing or the dead-end-check?

Gerd

________________________________________
Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag von AnkEric <ankeric.osm at gmail.com>
Gesendet: Donnerstag, 7. Mai 2020 12:25
An: mkgmap-dev at lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] Open question reg. new nearby-poi options

*Garmin:*
GPSMAP 60, Etrex Vista HCx: declutter is an option.
Extrex 30, GPSMAP 64: declutter is not an option, not anymore!
Garmin: "our customers prefer simple!" I don't!
And now mkgmap is expected to resolve:  + .

Garmin Search: Garmin Outdoor is the only GPS I know (in my possession) not
capable of searching for a POI along the upcoming route: fuel, bench,
picnic_table, pub, restaurant, swimming area.

Garmin Search (@Gerd: "POI search is much more important for me. The
rendering is of less importance.") is not always appropriate/sufficient.
Driving south I will search for a POI in direction south. Never make a
U-turn for a picnic_table, which would be a detour (2x distance). Garmin
Search will show direction (SW/S/SE/...), but it's not self-evident which of
found POI's are okay (for me).
And even more important: the most nearby POI might be on the other side of
the river. Navigation might be a huge detour by the next or previous bridge.
Or uphill 12% (or more). What's nearby?  Or "just" routing impossible?
Therefore: visual search on the map!

Garmin Rendering: Garmin Outdoor is the only GPS I know (in my possession)
not capable of selecting which category of POI I want to see now on the Map.
Declutter by category!
Show only selected category!

Garmin Outdoor GPS is still ignoring bicycle. Bicycle_parking is to be found
in: "Auto Services", "Wrecker Service" (my suggested and accepted solution
long time ago to openfietsmap as to render picnic_table, which is also:
"Auto Services").
Supermarket? Grocery.....!

*How to Declutter?*

*1. Decide what you want to declutter.*
I don't render barrier=bollard on Hiking or Car Map. On bicycle Map it's
"most prominent".
IMO: do not use nearby-poi-rules for wildcards. Never, ever. Unless you
prefer to create a BAD Map.

*2. Decide where you want to declutter.*
In a city declutter is more important (shop, shop, shop, more shops) than in
outside area, where a couple of benches and/or picnic-tables are the only
POI's in the area.
Anke (key user, navigator): "Are you serious? You want to declutter benches?
Useless and nonsense!"

*3. Decide how to declutter:*
- OR: {delete POI}
- OR: Do not delete, do render, but make label invisible: Font style = No
label (invisible). Selecting a POI (or hover over) will still show the name
(it's still there).
- OR: Do not delete, but make POI invisible (transparent). POI is still
searchable.
If above options don't help: ask Mike and Gerd (mkgmap) to help.

To decide: if declutter for a POI (not showing all) is okay (for you) than
ask yourself: should this POI be Rendered at all?
IMO: it's All or Nothing.

Declutter distance is bird's eye view distance. Sometimes routing distance
is far more than bird's eye view distance.
U-turn, across the river, other side of this wall/fence, parallel
cycleway/path or down below in the mountain gap. Both locations are having a
POI, rendered might be (!) only one. If I'm unlucky I will miss a bollard.
If I'm very unlucky this implies "3 months of liquid food" (and a bill of
the dentist).

Count of POI is – sometimes – very relevant.
During weekend or when travelling in a group I'm not interested in one
bench, or one picnic_table. I want more. After declutter I only can see on
the Map: there is at least one POI there, perhaps more, perhaps not.

Where to declutter?
My test version (using declutter):

    if (natural=tree) then
       is_in(landuse,residential,in)=false    [0x6618 resolution 24]
       is_in(landuse,grass,in)=true            [0x6618 resolution 24]
       is_in(natural,grassland,in)=true       [0x6618 resolution 24]
       is_in(tourism,camp_site,in)=true     [0x6618 resolution 24]
       is_in(leisure,park,in)=true               [0x6618 resolution 24]
       species=*                                      [0x6618 resolution 24]
So:
I don't want to see trees inside residential area (too many trees and
cluttering is more evident) unless natural, campsite, park or unless
"species" is specified.
In a "pinetum" (conifers park) I don't want any decluttering. Each tree is a
natural piece of art!
So my RFC would be: Make Nearby_poi a function (might be called by style
file) and not, or not only, an args option.

Effect on Routing (navigation)?

Some POI need to be, is preferred to be avoided.
Bollard is a warning. Warning should be for all bollards, not only for some.
Again: nearby might be a completely different path/route.
[bicycle=dismount] is a lifesaving warning! I will render a huge
[bicycle=dismount] POI on every highway=steps (steps are hard to see on the
GPS map) and I don't like any of those to be decluttered. Never!
Germany: bridge + step_count=2, incline=up (but dark forest) over Spree.
Elbe: step_count=6 (?), incline=down. In BaseCamp routing I created a
detour, on the ground Anke did not understand the detour... GPS saved us!
Other avoidances not to be decluttered: waterway=ford. Path crossing a
waterway without a bridge is routable. My assumption will be:
waterway=ditch. I can step over. A "ford" is different from a ditch (or OSM
missing bridge).
I Render all possible "challenges" as unpaved. I need to confirm (by setting
a viapoint) I do want this route navigation.

Some POI's will be a "routing block".
Several years ago in mkgmap routable = yes/no only applies to highways. But
then mkgmap improvement (!): barrier=gate + access=no/private, bicycle=no
will also be considered to be a showstopper.
In residential area's sometimes motorcar through route is blocked by a
[barrier=bollard] or [barrier=block]. More typical: blocked by
highway=path/cycleway segment, but not always.
Mkgmap routing: highway=residential (default access) + barrier=bollard,
implies (or explicitly): motorcar=no!
During construction period routing is blocked by a fence or gate or... And
again: [barrier=*] + [access=no] on POI. OSM does not always set the highway
to [access=no] as well. (Also: I don't always do so).

My suggestion:
Function: IS_ON_HIGHWAY = true/false (or return 0 (false) and 1,2,3,4,5 for
highway type).
Do not declutter if POI IS_ON_HIGHWAY(POI) = true.

I did some testing on declutter nearby POI (trees).
Test case: 7x [natural=tree] in a row (80 meters). Row is not perfectly
straight. Distance (average) = 13.5 meter, but not always exact same
distance.
"x" = tree is rendered.
"-" = tree is not rendered.

0x6618/unnamed:1  -->  x  x  x  x  x  x  x
0x6618/unnamed:11 -->  x  x  x  x  x  x  x
0x6618/unnamed:12 -->  -  x  x  x  x  x  x
0x6618/unnamed:13 -->  -  x -  x  x  x  x
0x6618/unnamed:14 -->  -  x  -  x  -  x  x
0x6618/unnamed:15 -->  -  -  x  -  -  x  -
0x6618/unnamed:25 -->  -  -  x  -  -  x  -
0x6618/unnamed:30 -->  -  -  -  -  x  -  -
0x6618/unnamed:45 -->  -  -  -  -  x  -  -
0x6618/unnamed:46 -->  -  -  -  -  -  -  -

Error: if distance is too large (46 meters on a 80 meters row) than zero
trees are rendered.
Gerd already warned: even 30 might be "too much of a distance"!
I expected: First, or Middle or Last to be always rendered.
In a park having 40 trees, distance:80 --> 2 trees left (which is oke and
nice!).

My Use Case (4): Duplicate "main feature tags" is "just a special case"
(btw, this is mkgmap default style!), but not unique.
In my own city I have mapped 2x [amenity=bicycle_parking].
1st is underground, large building
2nd is on the roof of 1st building, 50% size of the underground building.
No POI, so: area2poi.
On my own Map: both POI's are in collision for 50%!
In JOSM: both POI's are on very different locations (since building size is
different). I don't understand.
Attached is: "Collision_bicycle_parking_POI.osm".
Please look at JOSM rendering when selecting the area (is oke). On my mkgmap
map two POI's are 50% overlapping.
Collision_bicycle_parking_POI.osm
<http://gis.19327.n8.nabble.com/file/t344065/Collision_bicycle_parking_POI.osm>

My "conclusion":

POI-collision might be a better use case. Move one of the collision POI's
down for (number of POI-pixels-size) + (x=gap size). IMO, not hindered by
any know-how.

Use declutter only for (IMO): [natural=tree], [tourism=hotel],
[amenity=restaurant], [amenity=shop] (or [amenity=*]) (and 10 or more I did
overlook).
But even then: "Hotel Post" is a hotel and also a restaurant. Both having
the same (one and only) name. How to prevent declutter of the restaurant or
hotel?
Only option (IMO): declutter if and only if 1x POI is node and 2nd POI is
area2poi (or line2poi).

--
Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html
_______________________________________________
mkgmap-dev mailing list
mkgmap-dev at lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev