[mkgmap-dev] nearby POIs

Tue May 5 13:24:33 BST 2020

FWIW: I have done some testing as well. Or: trying to understand.

*Use Case (1): Area*

Area: building=hotel, tourism=hotel
Node: tourism=hotel
Area2poi + Node > 2 POI's (Hotel), 7 meters distance.
NOT Resolved, by any of next options:
 - 0x2b01/named:3, 0x2b01/unnamed:3
 - */named:3, */unnamed:3
 - 0x2b01/named:30, 0x2b01/unnamed:30
 - */named:30, */unnamed:30

*Use Case (2): Way*

Way: [historic=ruins] + [tourism=attraction] (6.38 meters).
Line2poi > start, mid, end > 3 POI's.
Expected, NOT Resolved by:
 - */named:3, */unnamed:3
Not Expected, Resolved by:
 - */named:30, */unnamed:30 (Distance = 30, way is 6.38 meters: 30 > 6.38)
Not expected, Resolved by:
 - 0x2c03/named:30, 0x2c03/unnamed:30 (Distance = 30, way is 6.38 meters: 30
> 6.38)

Remark:
I see only one POI on the Map. Which is OK. But when Searching (in BaseCamp)
I see two POI's (in Index). Garmin?
When I Select 2x POI and "Create Waypoint" (one after the other) I only get
one Waypoint. Garmin?
And... Waypoint icon (library) is different from MY - custom - icon
("historical building" ). Garmin?

*Use Case (3): Nodes*

Unrelated Nodes: [natural=tree]
Patch will Resolve (!) is OK.
Distance = x is Respected (!) is OK.

IMO-Remark (1): Testing for bench, picnic_table is (IMO) testing only.
Deleting nearby POI bench/picnic_table is - also – a loss of – useful –
information.
But it's a mkgmap-Renderers prerogative to either delete or not delete.

IMO-Remark (2): Deleting nearby POI bench/picnic_table would be OK (IMO) if
a COUNT can be added to the remaining POI. Similar to: "capacity=xx". But
even then: I won't delete nearby POI bench/picnic_table. I also won't delete
nearby buildings; -) 

Remark/Question (3): Rendering [natural=tree] (restricted by IS_IN()
function or having species=*) and declutter by nearby-poi-rules is only OK
if (and only IF) I can remove trees (and barriers) from index.
I am not capable to get this to work: *poi-excl-index=0x6618* (or:
poi-excl-index=0x6600-x6700). Therefore: rendering trees will make searching
impossible because of the huge number of trees (search for ALL POI).

*Use Case (4): Duplicate "main feature tags".*

"Ideally, every OSM element or object should be tagged with only one main
feature tag, to represent a single on-the-ground feature"
https://wiki.openstreetmap.org/wiki/One_feature,_one_OSM_element

One Node having:
tourism=hotel (0x2b01) OR amenity=restaurant (0x2a0?) + internet_access=wlan
(0x2f12)
will be Rendered by an Overlapping (Merged, Duplicated, Clashing) POI .
This is a Renderer Error since [internet_access=wlan] should be considered
as a property to hotel/restaurant, not as an – independent - on-the-ground
feature POI.
Error: Overlapping (Merged, Duplicated, Clashing) POI cannot be –
correctly/easily - interpreted by a user and is therefore useless Rendering
(on the Map).

One Node having:
[tourism=hotel] + [amenity=restaurant]: (or [tourism=viewpoint] +
[amenity=bench]) is to be considered as Bad OSM Mapping: one main feature
tag should be one node.
But this is a fact of OSM life.

Two "main feature tags" on "one node" will not be rendered unless "continue"
is used by Renderer.
In which case an Overlapping (Merged, Duplicated, Clashing, Error) POI will
be rendered. 
(@Gerd: last week I was not able to reproduce (Hotel + continue) +
Restaurant. Restaurant was "blocked"/"captured" by: "tourism=* & tourism!=no
[0x2c0d resolution 24]", which is the "red dot" showing in hotel (0x2b01) +
wlan (0x2f12) + unspecified tourism (0x2c0d) POI's).

Two "main feature tags" on "one node" will not be rendered (which is
preventing an "Overlap-Error"), but this will also imply a loss of
information: a "Hotel Restaurant" will be rendered as either [hotel] or
[restaurant], a "bench with a view" will be rendered as either bench or as
viewpoint.
This was my Feature Request: Move/Separate/Split
"Overlapping/Merged/Duplicated/Clashing Error" POI, representing multiple
"main feature tags".

AnkEric (Eric)

--
Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html