[mkgmap-dev] nearby POIs

Wed May 6 09:34:57 BST 2020

Hi Ticker,

OK, I think it will take longer to discuss the details. I think it is better to revert the changes in trunk and start a branch.

Gerd

________________________________________
Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap at jagit.co.uk>
Gesendet: Mittwoch, 6. Mai 2020 10:31
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] nearby POIs

Hi Gerd & Mike

I'd be concerned if this logic can move or delete [barrier=...] and
[highway=...] points that share nodes with ways. There are two aspects:
First, if --link-pois-to-ways then any access/speed restrictions should
still take place. Second is the presentation regardless of the -
-link... option, it will just look wrong and confusing and I agree with
Gerd's warning about having a wildcard rule.

Concerning the handling of named/unnamed and delete/merge:
I'd like to see a method that deletes all unnamed POI within {distance}
of a named one.

Also, I'd suggest interpreting the rules strictly in the defined order,
although I realise this doesn't quite make sense because named/unnamed
points might match different rules. I haven't explained this very well.

Ticker

On Wed, 2020-05-06 at 06:44 +0000, Gerd Petermann wrote:
> Hi all,
>
> thinking again about "Known problems:  The new implementation will
> not work well for the /all case because a group with different names
> is not detected as such"
> it is probably not a problem of the algo but of the docu.
> I can't think of any reason to remove a POI with a given type x named
> "abc" when it is close to another POI with the same type named "xyz"
> or when one of them is unnamed, the implementation is probably
> exactly what is wanted.
> So, I think I should simply add the mentioned grouping by type & name
> to the documentaion?
> I think we should define what happens when multiple rules match the
> same type.
> These 3 rules all match for a POI 0x3205 with name "Test" but it is
> not obvious which one will be used.
> 0x3205:30:merge-at-mid-point
> 0x3203-0x3207/named:20:delete-name
> 0x3200-0x331f:50
>
> With the current code the last one is used because of some internal
> sorting, probably not what was intended by the user.
> I see no obvious way to handle this. What should happen?
>
> BTW: I didn't try but I think default rules (*) with a radius > 5m
> are quite dangerous. Traffic lights or barriers may disappear. Also
> when you reander natural=tree
> POI you probably don't want to remove most of them. So, if you use
> them make sure that you specify rules for everything that should not
> be removed.
>
> Gerd
>
> ________________________________________
> Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag
> von Gerd Petermann <GPetermann_muenchen at hotmail.com>
> Gesendet: Mittwoch, 6. Mai 2020 07:04
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] nearby POIs
>
> Hi all,
>
> thanks for testing. I've just noticed that the jar file contained a
> modified points file, but I guess you all used your own style files.
> I thought about the possible effects on routing and found none.
>
> The new algo works like this:
> 1) Collect all generated POI and the corresponding nodes before
> adding them to the map
> 2) after all style rules were processed and WrongAngleFixer has moved
> points (and POI) to fix visible wrong angles the POI are
> deduplicated.
> This means they are
>  - grouped by type and name
>  - each group is processed so that
>    + the first matching rule is applied using the given radius:
> Iterate as long as there are multiple POI
>      * for each POI, build a group of all nearby POI
>      * select the biggest group
>      * calculate the center of that group
>      * select the POI that is closest to the center
>      * apply the action to the other POI of the group, maybe move the
> selected POI to the middle
>      * remove all POI handled in this group
>
> Known problems:
> - The new implementation will not work well for the /all case because
> a group with different names is not detected as such
>  - maybe identical POI are not removed with the delete-name case
> - Maybe there is an unwanted effect on rendering when WrongAngleFixer
> moves a point and the corresponding POI is not moved. This already
> happens sometimes and should be no big problem.
>
> If I find no solution for the first 2 problems today I'll revert
> trunk version and create a branch for further development.
>
> Gerd
>
> ________________________________________
> Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag
> von Ticker Berkin <rwb-mkgmap at jagit.co.uk>
> Gesendet: Dienstag, 5. Mai 2020 12:03
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] nearby POIs
>
> Hi Gerd
>
> That got rid of my multiple benches.
>
> Just looking at the log for the few other POI it also got rid of.
>
> It would be useful for the log message to include the distance
> between
> the POIs
>
> Ticker
>
> On Tue, 2020-05-05 at 09:19 +0000, Gerd Petermann wrote:
> > Hi all,
> >
> > attached is a patch that seems to work. I've kept the logging as
> > memory is not such a big problem.
> > I've not yet tested special cases like duplicated barrier nodes or
> > a
> > group of nodes where only some are within the tile boundary.
> >
> > Please check if your problems are solved with this version, a
> > binary
> > is here:
> > http://files.mkgmap.org.uk/download/469/mkgmap.jar
> >
> > Gerd
> >
> > ________________________________________
> > Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag
> > von Joris Bo <jorisbo at hotmail.com>
> > Gesendet: Dienstag, 5. Mai 2020 08:32
> > An: Development list for mkgmap
> > Betreff: Re: [mkgmap-dev] nearby POIs
> >
> > Hi,
> >
> >
> >
> > I have been testing the nearby poi rules as well with 4485
> >
> > A while I struggled thinking misconfiguration because I see nothing
> > happening but then after extending the ranges, an occasional poi
> > disappears. (toilet 0x2a0d, busstop 0x2f17, custom lift-gate
> > 0x6905)
> >
> >
> >
> > On the cmd line
> >
> > --nearby-poi-rules=*/unnamed:100:delete-poi,*/named:100:delete-poi
> >
> >
> >
> > On my densed big city area (Antwerpen) In that case I expect maybe
> > a
> > couple of thousand benches, trees and bicycle parkings disappear
> > which do not.
> >
> >
> >
> > Can I help testing better by increasing some logging? How could I
> > do
> > that?
> >
> >
> >
> > Kind regards, joris
> >
> >
> >
> > Silo’s (0x2a19) don’t disappear / N51° 11.992' E4° 24.916'
> >
> > An occasional lift gate (0x6905) does disappear
> >
> > [cid:image001.jpg at 01D622B7.BA7DE260]
> >
> >
> >
> > Bicycle stands (0x2f18): don’t disappear
> >
> > N51° 13.685' E4° 24.281'
> >
> > [cid:image002.jpg at 01D622B7.BA7DE260]
> >
> >
> >
> >
> >
> > -----Oorspronkelijk bericht-----
> > Van: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> Namens
> > Ticker Berkin
> > Verzonden: maandag 4 mei 2020 16:13
> > Aan: mkgmap development <mkgmap-dev at lists.mkgmap.org.uk>
> > Onderwerp: Re: [mkgmap-dev] nearby POIs
> >
> >
> >
> > Hi Mike
> >
> >
> >
> > No, I just have --nearby-poi-rules=0x6605:30
> >
> >
> >
> > Gerd has explained why I see a message from NearbyPoiHandler about
> > a
> > POI for that wasn't 0x6605 - the logging of the removal of an exact
> > duplicate has moved from StyledConverter
> >
> >
> >
> > Ticker
> >
> >
> >
> > On Mon, 2020-05-04 at 14:35 +0100, Mike Baggaley wrote:
> >
> > > Hi Ticker, have you got a --nearby-poi-rules-config option as
> > > well?
> >
> > >
> >
> > > Cheers,
> >
> > > Mike
> >
> > >
> >
> > > -----Original Message-----
> >
> > > From: Ticker Berkin [mailto:rwb-mkgmap at jagit.co.uk]
> >
> > > Sent: 04 May 2020 11:33
> >
> > > To: Development list for mkgmap <mkgmap-dev at lists.mkgmap.org.uk<m
> > > ai
> > > lto:mkgmap-dev at lists.mkgmap.org.uk>>
> >
> > > Subject: Re: [mkgmap-dev] nearby POIs
> >
> > >
> >
> > > OK, looking up the # as a way instead gives a polygon that
> > > matches
> > > the
> >
> > > description and would generate a typ code as per the message
> >
> > >
> >
> > > I was more worried about it logging messages about POI with typ
> > > codes
> >
> > > that I hadn't mentioned in rules and not saying anything about
> > > the
> > > one
> >
> > > I had.
> >
> > >
> >
> > > I get the same behaviour with just --nearby-poi-rules=0x6605:30
> >
> > >
> >
> > > Ticker
> >
> > >
> >
> > > On Mon, 2020-05-04 at 10:14 +0000, Gerd Petermann wrote:
> >
> > > > Hi Ticker,
> >
> > > >
> >
> > > > the new option doesn't work well, Mike and I are working on it.
> > > > See
> >
> > > > http://gis.19327.n8.nabble.com/nearby-POIs-tp5962630p5964759.ht
> > > > ml
> >
> > > > The log messages are for POIs generated from areas, so the
> >
> > > > "generated from" ids are either ways or multipolygon relations.
> >
> > > >
> >
> > > > Gerd
> >
> > > >
> >
> > > >
> >
> > > > ________________________________________
> >
> > > > Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:
> > > > mkgmap-dev-bounces at lists.mkgmap.org.uk>> im Auftrag
> >
> > > > von Ticker Berkin <rwb-mkgmap at jagit.co.uk<mailto:
> > > > rwb-mkgmap at jagit.co.uk>>
> >
> > > > Gesendet: Montag, 4. Mai 2020 12:04
> >
> > > > An: mkgmap development
> >
> > > > Betreff: [mkgmap-dev] nearby POIs
> >
> > > >
> >
> > > > Hi Mike & Gerd
> >
> > > >
> >
> > > > I'm trying --nearby-poi-rules=0x6605:30:merge-at-mid-point
> >
> > > >
> >
> > > > with, in points:
> >
> > > >
> >
> > > > amenity=bench [0x6605 resolution 24 continue]
> >
> > > >
> >
> > > > and the resultant map is showing benches close to each other (<
> > > > 10
> >
> > > > m)
> >
> > > >
> >
> > > > and, in the log file I'm getting messages like:
> >
> > > >
> >
> > > > INFO: uk.me.parabola.mkgmap.osmstyle.NearbyPoiHandler
> >
> > > >  ../mapHants/74210001.osm.pbf: Removed duplicate POI with type
> >
> > > > 0x2d02
> >
> > > > The Dungeon for element generated from 159255400
> >
> > > > INFO: uk.me.parabola.mkgmap.osmstyle.NearbyPoiHandler
> >
> > > >  ../mapHants/74210001.osm.pbf: Removed duplicate POI with type
> >
> > > > 0x2a07
> >
> > > > Wah Ying for element generated from 468906008
> >
> > > >
> >
> > > > The "generated from" number doesn't seem to correspond to a
> > > > relevant
> >
> > > > OSM node and the message doesn't have the trailing "and
> > > > moved..."
> >
> > > > that
> >
> > > > I would have expected.
> >
> > > >
> >
> > > > Ticker
> >
> > > > _______________________________________________
> >
> > > > mkgmap-dev mailing list
> >
> > > > mkgmap-dev at lists.mkgmap.org.uk<mailto:
> > > > mkgmap-dev at lists.mkgmap.org.uk>
> >
> > > > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> >
> > > > _______________________________________________
> >
> > > > mkgmap-dev mailing list
> >
> > > > mkgmap-dev at lists.mkgmap.org.uk<mailto:
> > > > mkgmap-dev at lists.mkgmap.org.uk>
> >
> > > > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> >
> > >
> >
> > >
> >
> > _______________________________________________
> >
> > mkgmap-dev mailing list
> >
> > mkgmap-dev at lists.mkgmap.org.uk<mailto:
> > mkgmap-dev at lists.mkgmap.org.uk>
> >
> > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> > _______________________________________________
> > mkgmap-dev mailing list
> > mkgmap-dev at lists.mkgmap.org.uk
> > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
mkgmap-dev at lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev