Re: [mkgmap-dev] Test if POI is part of a line

[ankeric.osm]

Hi Gerd,

I also have a - similar? - issue implementing poi2line.
I cannot Add or Delete poi2line nodes.

Perhaps (as you said):
"One problem with your suggested solution is that the current implementation in 
mkgmap processes (tagged) nodes before lines".

In 'lines' this is working OK:

access:conditional = 'no @ sunset-sunrise'  { delete access:conditional }
access:conditional = 'no @ sunset - sunrise'{ delete access:conditional }
access:conditional = 'no @ (sunset-sunrise)'{ delete access:conditional }
access:conditional = 'no @ (sunset - sunrise)'  { delete access:conditional }

opening_hours  = '24/7'{ delete 
opening_hours } 
opening_hours  = '(24/7)' { delete 
opening_hours } 

and 50 more lines of script because these tags are useless and/or polluting the 
map and/or default and/or needless. IMO!

But once I add 'omsid()=...' to mkgmap it doesn't work anymore to remove 
line2poi.

highway=unclassified & osmid()=912437951 {delete smoothness; delete 
opening_hours}

In next example I delete all tags (don't want to render this highway), highway 
is deleted (not rendered) but line2poi is still rendered.

highway=cycleway & osmid()=1011546906 {deletealltags}

I also cannot ADD a line2poi tag:

highway=unclassified & osmid()=176775241 {set opening_hours="may be closed 
during sport events"}

I want to add private tags (line2poi), IMO tags, subjective tags, 'necessary' 
tags (IMO) that are not allowed on OSM (f.i.: bicycle=dismount, scenic=yes, 
which are only 'allowed' if a (traffic)sign is 'on the ground' to confirm 
dismount/scenic).

AnkEric

-Original Message-
From: mkgmap-dev  On Behalf Of Gerd 
Petermann
Sent: maandag 10 oktober 2022 12:49
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] Test if POI is part of a line

Hi Felix,

the current implementation of the link-pois-to-ways doesn't transfer the access 
tag(s) to the way. It just creates a route restriction which tells Garmin that 
it must not route the given vehicles through the barrier. Older implementations 
created a short stub close to the barrier node.

Gerd



Von: mkgmap-dev  im Auftrag von Felix 
Hartmann 
Gesendet: Montag, 10. Oktober 2022 12:13
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Test if POI is part of a line

Also I don't like using --link-pois-to-ways to put an access=private onto a 
road - and then remove this road. Because in the case of a park - the 
footways/pathes on both sides of the gate do exist. So an access=private does 
not actually apply to the road. So it's correct to show the road, and show the 
gate that is blocking the road. I think this is better that deleting that road 
because of the gate.

On Mon, 10 Oct 2022 at 11:47, Felix Hartmann 
mailto:extremecar...@gmail.com>> wrote:
Hi Gerd,

No  --add-poi-to-lines creates points from a line that has certain tags. What I 
try to achieve is actually to remove points that are NOT part of a line / or  
part of a line that is not rendered in the map. There is no reason to show a 
gate if you don't have a line/road.So essentially for me there is no sense to 
show a gate for me if it is not part of a routable line.
However points created by add-pois-to-lines are also not what I want - because 
it would show the gate in an incorrect position.

So the clutch of using --link-pois-to-ways  to get the access tags onto the 
line - then never show an actual barrier=gate/highway=gate but only show one 
created by the --add-poi-to-line command?  The logical solution is to really 
only show a gate where it is tagged, but only if the map is creating a routable 
line for it and remove all other barrier=* / highway=gate / entrance=yes POI.


If this is too much work to implement - then drop it. But as far as I 
understand right now there is no good solution by mkgmap for this. The same 
would be for traffic lights - if you remove a road because your map does not 
show private roads - but a private road has a traffic light - this traffic 
light should not be in the map either. And yes I know the dilemma - we need 
points to be looked at pre lines for --link-pois-to-ways to work, but for some 
other things we would need to look at them later again. So this would need to 
be some kind of seond_finalize rules in the points file that is executed after 
the lines file - and removes points from the map again. It's not a big problem 
- but right now this really makes it inconvenient to put gates into your map - 
as 75% of gates are just cluttering up the map without providing any 
information to the user (except if you want to create a cataster type of map 
showing everything). Leaving gates out completely on the other hand makes it 
very ha
   rd to show for example with parks where people can enter and where not. As 
very often there are service entries to parks not open to public - so these are 
the main ones that we want to 

Re: [mkgmap-dev] option link-pois-to-ways information

[ankeric.osm]

Hi Gerd,

Question ("On Topic" or "Off Topic"):

Has mkgmap (Internal tags) an option to "Set mkgmap:dead-end = true"?

I do read:
mkgmap:dead-end-check   Set to false to disable the dead-end-check for a 
specific way   report-dead-ends
But: what is "dead-end-check"?

I would like to have this option:

highway=service | highway=track & mkgmap:dead-end = true {set access=private}
(Do not ignore a dead-end mountain valley, f.i.)
(OsmAnd can handle "access=private". Garmin cannot, but I can manually ignore)

I do use:
bicycle=destination { set highway=service; set bicycle=yes; set 
mkgmap:throughroute=no }  

But I don't use:
"mkgmap:throughroute=no" for navigation. So: useless???
Because I don't know how to...

BTW, FWIW:
In the Netherlands "they" have set {access=private} on ALL "highway=service" 
"service=driveway" (oké, only in my region).
Making Address navigation by Garmin impossible.

AnkEric


-Original Message-
From: mkgmap-dev  On Behalf Of Gerd 
Petermann
Sent: woensdag 16 februari 2022 10:25
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] option link-pois-to-ways information

Hi Ticker,

reg. routing problems in Basecamp:  Maybe you hit the problem described for 
--max-routing-island-len?

Gerd


Von: mkgmap-dev  im Auftrag von Ticker 
Berkin 
Gesendet: Dienstag, 15. Februar 2022 17:41
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] option link-pois-to-ways information

Hi Gerd

highway=street_lamp was just an example of a POI that can get linked to a WAY 
that can be ignored. There are others that are valid OSM tagging that are 
irrelevant to the highway behaviour.

Actually, regardless of --link-pois-to-ways, there is a problem in the scenario 
where there is typical road system linked to a small road system by just a road 
with mkgmap:throughroute=no and a footway.
BaseCamp and the eTrex 30x really will route over the footway to get into the 
small road system. MapSource and, I think, the eTrex HCx will use the road.

I realise that this set-up seems unlikely, but can happen if there is an 
inconsistency in the tagging of roads in the small system that results in one 
not having mkgmap:throughroute=no that is joined to the footway. My example 
happened in a business park.

My style makes this problem more likely to happen, while also trying to fix it, 
by not setting mkgmap:throughroute=no unless there seems to be a good reason 
for it. Good reasons are when there is a barrier on a service road. This is the 
test I want to improve.

Ticker

On Tue, 2022-02-15 at 14:12 +, Gerd Petermann wrote:
> Hi Ticker,
>
> if you find highway=street_lamp nodes on highway=* ways those are 
> errors and should be fixed in OSM.
> Street lamps are normally mapped along the road, not on the road.
>
> Maybe you meant highway=traffic_signals?
>
> Besides that Basecamp should never route a car over a footway. That 
> sounds like an error in the map data produced by mkgmap or maybe you 
> used wrong routing settings. Please let me know how to reproduce.
>
> No idea if your proposed change would improve routing, but feel free 
> to experiment with that.
>
> Gerd
>
> 
> Von: mkgmap-dev  im Auftrag 
> von Ticker Berkin 
> Gesendet: Dienstag, 15. Februar 2022 13:37
> An: mkgmap development
> Betreff: [mkgmap-dev] option link-pois-to-ways information
>
> Hi all
>
> To improve routing, I'd like to get information about the POIS that 
> are being linked to a WAY that can be used as part of the style/lines 
> processing.
>
> The problem I'm trying to solve is to restrict car routing through 
> some types of very low level roads (eg service) when there is a 
> barrier.
> Setting mkgmap:throughroute=no on these works nicely with MapSource 
> and older devices but BaseCamp and newer devices will happily route 
> over a footpath to avoid a throughroute=no section.
>
> At the moment, with --link-pois-to-ways, if the POI has a barrier or 
> highway tag, mkgmap:way-has-pois is set true. This can be tested by 
> lines, inc/access etc, but there is no way to find out if it is a 
> significant barrier or something like highway=street_lamp.
>
> points processing can set mkgmap: access & road_speed/class variables 
> that are handled by inbuild code after lines processing to imposes 
> more restrictions on the way and/or reduces speed/class; this is no 
> use for what I want to do.
>
> Possibilities are:
> 1/ have options to say which POI tag/value combinations cause
>link-pois-to-ways
> 2/ set new variables on the way, eg mkgmap:barrier_tags/highway_tags,
>which are a list of distinct POI highway/barrier tag values.
>
> Ticker
>
>
>
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> 

Re: [mkgmap-dev] Basecamp crashes on search if searching for many 2+ word phrases

[ankeric.osm]

Next:

 

Search by OSM_GENERIC = Crash

Restart

Search by OSM_GENERIC = Crash

 

Switch to my own Map

Search for “338 dijkweg, andijk” by my own Map: NO Crash!

Restart

Search for “338 dijkweg, andijk” by my own Map: NO Crash!

 

Restart

Search for “338 dijkweg, andijk” by OpenFietsMap: NO Crash!

 

Restart

Search for “338 dijkweg, andijk” by OSM_GENERIC: Crash!

 

So (+ ) there is one Map (and one Map only) where the crash occurs.

As long as this is not my own Map (or OpenFietsMap) my own Map is safe for 
Crashing.

Just need one Map for Crashing purposes only….?

 

To reproduce: more than one Map might be required ?

 

Eric (AnkEric)

 

 

From: ankeric@gmail.com  
Sent: woensdag 2 juni 2021 17:02
To: 'Development list for mkgmap' 
Subject: RE: [mkgmap-dev] Basecamp crashes on search if searching for many 2+ 
word phrases

 

Re-installed all my Maps (now: 6x):

 

Search for “338 dijkweg, andijk” by OpenFietsMap: oké, no crash

Not even after restart BaseCamp.

 

Switch to my own Map

Search for “338 dijkweg, andijk” by my own Map: crash!

 

Switch to OpenFietsMap

Search for “338 dijkweg, andijk” by OpenFietsMap: : oké, no crash

 

Switch to my own Map

Search for “338 dijkweg, andijk” by my own Map: crash!

 

Must be a very simple explanation; -))

 

What also might be relevant:

Last year vacation I did install my own Bike and my own Hike Map on GpsMap 66.

But also (just for fun): OSM_GENERIC Map (Joris Bo).

My own Maps use a different Categorization for POI’s (Attractions, AutoService, 
etc.).

Different from OSM_Generic.

This was my doing: a change for OpenFietsMap to allow search for picnic_table 
and bicycle_parking on the map. 

To find bicycle_parking I have to Search for “Auto Services” + “Wrecker 
Service”. 

Having OSM_Generic installed I could not search by Category. Not anymore.

Is the crash the result of different POI Categorization by two different sets 
of Maps?

 

If the crash occurs, BaseCamp will find some hits, continues the search and 
after a few (of more) seconds BaseCamp crashes on not finding any more….

So finding is not the issue, not finding is the issue.

 

Oké, very wild guess….

 

Eric (AnkEric)

 

From: ankeric@gmail.com   
mailto:ankeric@gmail.com> > 
Sent: woensdag 2 juni 2021 15:08
To: 'Development list for mkgmap' mailto:mkgmap-dev@lists.mkgmap.org.uk> >
Subject: RE: [mkgmap-dev] Basecamp crashes on search if searching for many 2+ 
word phrases

 

Hi Felix,

 

I don’t appreciate your post; -))

Please let sleeping dogs lie.

 

Oké, get to the point.

 

BaseCamp version is relevant. I assume.

 

I tried to reproduce and since BaseCamp is remembering search history, this 
should be easy.

I don’t abide my own rule (don’t search by BaseCamp); -)

 

After 15 minutes I gave up. No success in reproducing a crash.

 

All searches (10x different) contained space(s) and comma!

 

So I moved mouse to “Exit”, wanted to give up, but before I could Exit, 
BaseCamp crashed. On my last search??? Oké, what was my last search? I don’t 
know.

 

So restart testing.

10x success, so mood problem.

 

But then:

Search for “338 dijkweg, andijk”

Crash.

 

Restart BaseCamp

Search for “338 dijkweg, andijk”

Crash.

 

Reproduced 10 times in a row!

 

Oké, now search for Search for “338 dijkweg, andijk” by using: Find Addresses 
(Ctrl+Alt+A)

Now BaseCamp search will correct my incorrect capitalisation before search is 
started: 338 + Dijkweg + Andijk

Success, no crash!

And address has been found!

 

Oke, now search for Search for “338 dijkweg, andijk” (not by Ctrl+Alt+A, but in 
Search box)

Success, no crash!

 

Reproduced 10 times in a row!

 

Not oké, my test is NOT oké!

This is only true IF (and only if) I keep the Ctrl+Alt+A window open!

I’m allowed to search (textbox) to different text (and BaseCamp will find 
those) en then again for  “338 dijkweg, andijk” (success), but as soon as I 
close Ctrl+Alt+A window, search for “338 dijkweg, andijk” won’t find any 
results and will crash after a few seconds.

 

Exit BaseCamp 

Start BaseCamp

Search for “338 dijkweg, andijk” (not by Ctrl+Alt+A, but in Search box, 
incorrect capitalization)

Again: crash!

 

Search for “andijk”

No crash!

 

Exit BaseCamp 

Start BaseCamp

Search for “338 Dijkweg, Andijk” (correct capitalization)

Again: crash!

 

Exit BaseCamp 

Start BaseCamp

Search for “338 Dijkweg, Andijk” or “338 dijkweg, andijk”

BaseCamp won’t find the address!

BaseCamp only finds “Dijkwegpad, Amsterdam”

BaseCamp Shows 1x result

Searching……

Again: crash!

 

Next step might be:

Uninstall ALL maps.

Reinstall OpenFietsMap (Gerd also uses OpenFietsMap for testing purposes)

But will uninstall force a BaseCamp index update?

 

If I’m very lucky I can reproduce…?

 

But I’m assuming this is BaseCamp error and not mkgmap?

 

BTW: “338 Dijkweg, Andijk” is not a privacy issue. This is a pub, end-of-life 
after 125 

Re: [mkgmap-dev] Basecamp crashes on search if searching for many 2+ word phrases

[ankeric.osm]

Re-installed all my Maps (now: 6x):

 

Search for “338 dijkweg, andijk” by OpenFietsMap: oké, no crash

Not even after restart BaseCamp.

 

Switch to my own Map

Search for “338 dijkweg, andijk” by my own Map: crash!

 

Switch to OpenFietsMap

Search for “338 dijkweg, andijk” by OpenFietsMap: : oké, no crash

 

Switch to my own Map

Search for “338 dijkweg, andijk” by my own Map: crash!

 

Must be a very simple explanation; -))

 

What also might be relevant:

Last year vacation I did install my own Bike and my own Hike Map on GpsMap 66.

But also (just for fun): OSM_GENERIC Map (Joris Bo).

My own Maps use a different Categorization for POI’s (Attractions, AutoService, 
etc.).

Different from OSM_Generic.

This was my doing: a change for OpenFietsMap to allow search for picnic_table 
and bicycle_parking on the map. 

To find bicycle_parking I have to Search for “Auto Services” + “Wrecker 
Service”. 

Having OSM_Generic installed I could not search by Category. Not anymore.

Is the crash the result of different POI Categorization by two different sets 
of Maps?

 

If the crash occurs, BaseCamp will find some hits, continues the search and 
after a few (of more) seconds BaseCamp crashes on not finding any more….

So finding is not the issue, not finding is the issue.

 

Oké, very wild guess….

 

Eric (AnkEric)

 

From: ankeric@gmail.com  
Sent: woensdag 2 juni 2021 15:08
To: 'Development list for mkgmap' 
Subject: RE: [mkgmap-dev] Basecamp crashes on search if searching for many 2+ 
word phrases

 

Hi Felix,

 

I don’t appreciate your post; -))

Please let sleeping dogs lie.

 

Oké, get to the point.

 

BaseCamp version is relevant. I assume.

 

I tried to reproduce and since BaseCamp is remembering search history, this 
should be easy.

I don’t abide my own rule (don’t search by BaseCamp); -)

 

After 15 minutes I gave up. No success in reproducing a crash.

 

All searches (10x different) contained space(s) and comma!

 

So I moved mouse to “Exit”, wanted to give up, but before I could Exit, 
BaseCamp crashed. On my last search??? Oké, what was my last search? I don’t 
know.

 

So restart testing.

10x success, so mood problem.

 

But then:

Search for “338 dijkweg, andijk”

Crash.

 

Restart BaseCamp

Search for “338 dijkweg, andijk”

Crash.

 

Reproduced 10 times in a row!

 

Oké, now search for Search for “338 dijkweg, andijk” by using: Find Addresses 
(Ctrl+Alt+A)

Now BaseCamp search will correct my incorrect capitalisation before search is 
started: 338 + Dijkweg + Andijk

Success, no crash!

And address has been found!

 

Oke, now search for Search for “338 dijkweg, andijk” (not by Ctrl+Alt+A, but in 
Search box)

Success, no crash!

 

Reproduced 10 times in a row!

 

Not oké, my test is NOT oké!

This is only true IF (and only if) I keep the Ctrl+Alt+A window open!

I’m allowed to search (textbox) to different text (and BaseCamp will find 
those) en then again for  “338 dijkweg, andijk” (success), but as soon as I 
close Ctrl+Alt+A window, search for “338 dijkweg, andijk” won’t find any 
results and will crash after a few seconds.

 

Exit BaseCamp 

Start BaseCamp

Search for “338 dijkweg, andijk” (not by Ctrl+Alt+A, but in Search box, 
incorrect capitalization)

Again: crash!

 

Search for “andijk”

No crash!

 

Exit BaseCamp 

Start BaseCamp

Search for “338 Dijkweg, Andijk” (correct capitalization)

Again: crash!

 

Exit BaseCamp 

Start BaseCamp

Search for “338 Dijkweg, Andijk” or “338 dijkweg, andijk”

BaseCamp won’t find the address!

BaseCamp only finds “Dijkwegpad, Amsterdam”

BaseCamp Shows 1x result

Searching……

Again: crash!

 

Next step might be:

Uninstall ALL maps.

Reinstall OpenFietsMap (Gerd also uses OpenFietsMap for testing purposes)

But will uninstall force a BaseCamp index update?

 

If I’m very lucky I can reproduce…?

 

But I’m assuming this is BaseCamp error and not mkgmap?

 

BTW: “338 Dijkweg, Andijk” is not a privacy issue. This is a pub, end-of-life 
after 125 years and then locals bought the pub and they will reopen next month 
(1 July).

So this is “promotion”: old name “Het Ankertje”, new name “Eetcafé Sels”. I did 
therefore search for it.

 

Eric (AnkEric)

 

From: mkgmap-dev mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk> > On Behalf Of Felix Hartmann
Sent: woensdag 2 juni 2021 12:15
To: Development list for mkgmap mailto:mkgmap-dev@lists.mkgmap.org.uk> >
Subject: Re: [mkgmap-dev] Basecamp crashes on search if searching for many 2+ 
word phrases

 

well it clearly only happens with a blank in the name. That is the most common 
factor. Never seen one where the name is a single word. And in recent versions 
of Basecamp the search actually became really useful - it is way faster than at 
the beginning, it finds all addresses / POI - just missing the nice POI 
category search. I will try to get a minimalist style to crash. If that doesn't 
work maybe we can introduce _ instead of blanks? Better not being able to 

Re: [mkgmap-dev] Basecamp crashes on search if searching for many 2+ word phrases

[ankeric.osm]

Hi Felix,

 

Uninstall all Maps (10x).

 

Before 1x Map is installed (Global Map only) BaseCamp won’t find any and won’t 
crash.

 

Install OpenFietsMap_2021-05-29.

 

I can now reproduce by OpenFietsMap:

Search by OpenFietsMap for “338 dijkweg, andijk”

crash!

 

Search by OpenFietsMap + Ctrl+Alt+A: 13x  found, success

 

But also:

Search by OpenFietsMap + Ctrl+Alt+A: 13x  found, success

Close Ctrl+Alt+A window

Search by OpenFietsMap + (text box): 5x  found, success

 

My first Test would crash!

 

But now:

I cannot reproduce any crash. Not anymore!

 

Is my Search Item now cached in index ?

 

Even after uninstall + install OpenFietsMap_2021-05-29:

I cannot reproduce any crash. Not anymore!

 

So my shout of cheer: One time success to crash only. 

 

Eric (AnkEric)

 

 

From: mkgmap-dev  On Behalf Of Felix 
Hartmann
Sent: woensdag 2 juni 2021 12:15
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] Basecamp crashes on search if searching for many 2+ 
word phrases

 

well it clearly only happens with a blank in the name. That is the most common 
factor. Never seen one where the name is a single word. And in recent versions 
of Basecamp the search actually became really useful - it is way faster than at 
the beginning, it finds all addresses / POI - just missing the nice POI 
category search. I will try to get a minimalist style to crash. If that doesn't 
work maybe we can introduce _ instead of blanks? Better not being able to 
search for two words normally with crash vs not crashing. Well only for 0x1??? 
and 0x2??? POI. I do feel like if Basecamp can first find a 0x? type of POI 
it will not crash. That is what is causing those really random results.

 

Last message for now - need to get some fresh air after working 6 hours 
straight this morning. But will try to drill down the problem a bit more 
tonight.

 

On Wed, 2 Jun 2021 at 13:03, mailto:ankeric@gmail.com> > wrote:

Yes, this has been happening for a very long time (longer than my memory lane).

 

My “facts”:

*   Not possible to reproduce;
*   Sometimes it will take hours before the crash occurs. So, I don’t 
agree: “if a good search already has been executed (single word), then the 
crash rarely occurs”.
*   Long, long ago I have tested by uninstall all mkgmaps, which left over 
City Navigator 2007 (yes; 2007). And still: the error did occur. But harder to 
reproduce;
*   But also: I have the impression (no fact) that more Maps increases the 
chance of crashing;
*   I have never seen GPS crash on search (Vista HCx, Etrex 30, GPSMAP 
62/66)
*   Find Addresses (Ctrl+Alt+A) will never crash (so: work-around);
*   I have also seen strange addresses found, which do not match my search 
criteria.
*   And – lol – I could reproduce a BaseCamp search which will take 10 
minutes to respond. Oeps, or was this a GPS search? Is this a search where 
BaseCamp will crash (impatience, no retry, no error handling) and GPS will try 
for 10 minutes and succeed???

 

My work-around:

Do not use BaseCamp for any Search. Not ever! I use my smartphone + OsmAnd or 
Google search on second PC monitor.

I will only test a new version of BaseCamp and until now, it’s always not oké. 
Still not oké.

In BaseCamp I can only find an object, if I know where it is….

 

A BaseCamp crash is 99% harmless, but at 1% I lose information (in which case 
always (...) relevant information, so bad for my mood).

 

But I might have to apologize to Garmin.

I have always considered BaseCamp to be extreme bad software, but perhaps 
Garmin is not to blame???

 

If (but only “if”) you are gone investigate and mkgmap might be the cause, I 
could try “memory lane”.

I have posted several times on Garmin Vendor forum about searching and not 
finding or finding the wrong answers or crashing. 

I even might have found a way to reproduce ?

But these posting are all in Dutch language, so therefore: “If and only if”.

 

Sorry, too many “???”. 

But I assumed I had managed to suppress my - bad - memories

 

Eric (AnkEric)

 

From: mkgmap-dev <  
mkgmap-dev-boun...@lists.mkgmap.org.uk> On Behalf Of Felix Hartmann
Sent: woensdag 2 juni 2021 11:20
To: Development list for mkgmap <  
mkgmap-dev@lists.mkgmap.org.uk>
Subject: Re: [mkgmap-dev] Basecamp crashes on search if searching for many 2+ 
word phrases

 

Basecamp just closes 0-3 seconds after entering that term into the search bar. 
No warning, no error notice, nothing. Seems to have been happening a long time 
already. Okay this evening I will try to produce a map as small as possible 
that still crashes. I do not have much time now anymore - but will try if 
removing --split-name-index changes something. I kinda feel it has something to 
do with split-name-index.

 

On Wed, 2 Jun 2021 at 12:07, Gerd Petermann mailto:gpetermann_muenc...@hotmail.com> > wrote:

Hi Felix,

I 

Re: [mkgmap-dev] Basecamp crashes on search if searching for many 2+ word phrases

[ankeric.osm]

Hi Felix,

 

I don’t appreciate your post; -))

Please let sleeping dogs lie.

 

Oké, get to the point.

 

BaseCamp version is relevant. I assume.

 

I tried to reproduce and since BaseCamp is remembering search history, this 
should be easy.

I don’t abide my own rule (don’t search by BaseCamp); -)

 

After 15 minutes I gave up. No success in reproducing a crash.

 

All searches (10x different) contained space(s) and comma!

 

So I moved mouse to “Exit”, wanted to give up, but before I could Exit, 
BaseCamp crashed. On my last search??? Oké, what was my last search? I don’t 
know.

 

So restart testing.

10x success, so mood problem.

 

But then:

Search for “338 dijkweg, andijk”

Crash.

 

Restart BaseCamp

Search for “338 dijkweg, andijk”

Crash.

 

Reproduced 10 times in a row!

 

Oké, now search for Search for “338 dijkweg, andijk” by using: Find Addresses 
(Ctrl+Alt+A)

Now BaseCamp search will correct my incorrect capitalisation before search is 
started: 338 + Dijkweg + Andijk

Success, no crash!

And address has been found!

 

Oke, now search for Search for “338 dijkweg, andijk” (not by Ctrl+Alt+A, but in 
Search box)

Success, no crash!

 

Reproduced 10 times in a row!

 

Not oké, my test is NOT oké!

This is only true IF (and only if) I keep the Ctrl+Alt+A window open!

I’m allowed to search (textbox) to different text (and BaseCamp will find 
those) en then again for  “338 dijkweg, andijk” (success), but as soon as I 
close Ctrl+Alt+A window, search for “338 dijkweg, andijk” won’t find any 
results and will crash after a few seconds.

 

Exit BaseCamp 

Start BaseCamp

Search for “338 dijkweg, andijk” (not by Ctrl+Alt+A, but in Search box, 
incorrect capitalization)

Again: crash!

 

Search for “andijk”

No crash!

 

Exit BaseCamp 

Start BaseCamp

Search for “338 Dijkweg, Andijk” (correct capitalization)

Again: crash!

 

Exit BaseCamp 

Start BaseCamp

Search for “338 Dijkweg, Andijk” or “338 dijkweg, andijk”

BaseCamp won’t find the address!

BaseCamp only finds “Dijkwegpad, Amsterdam”

BaseCamp Shows 1x result

Searching……

Again: crash!

 

Next step might be:

Uninstall ALL maps.

Reinstall OpenFietsMap (Gerd also uses OpenFietsMap for testing purposes)

But will uninstall force a BaseCamp index update?

 

If I’m very lucky I can reproduce…?

 

But I’m assuming this is BaseCamp error and not mkgmap?

 

BTW: “338 Dijkweg, Andijk” is not a privacy issue. This is a pub, end-of-life 
after 125 years and then locals bought the pub and they will reopen next month 
(1 July).

So this is “promotion”: old name “Het Ankertje”, new name “Eetcafé Sels”. I did 
therefore search for it.

 

Eric (AnkEric)

 

From: mkgmap-dev  On Behalf Of Felix 
Hartmann
Sent: woensdag 2 juni 2021 12:15
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] Basecamp crashes on search if searching for many 2+ 
word phrases

 

well it clearly only happens with a blank in the name. That is the most common 
factor. Never seen one where the name is a single word. And in recent versions 
of Basecamp the search actually became really useful - it is way faster than at 
the beginning, it finds all addresses / POI - just missing the nice POI 
category search. I will try to get a minimalist style to crash. If that doesn't 
work maybe we can introduce _ instead of blanks? Better not being able to 
search for two words normally with crash vs not crashing. Well only for 0x1??? 
and 0x2??? POI. I do feel like if Basecamp can first find a 0x? type of POI 
it will not crash. That is what is causing those really random results.

 

Last message for now - need to get some fresh air after working 6 hours 
straight this morning. But will try to drill down the problem a bit more 
tonight.

 

On Wed, 2 Jun 2021 at 13:03, mailto:ankeric@gmail.com> > wrote:

Yes, this has been happening for a very long time (longer than my memory lane).

 

My “facts”:

*   Not possible to reproduce;
*   Sometimes it will take hours before the crash occurs. So, I don’t 
agree: “if a good search already has been executed (single word), then the 
crash rarely occurs”.
*   Long, long ago I have tested by uninstall all mkgmaps, which left over 
City Navigator 2007 (yes; 2007). And still: the error did occur. But harder to 
reproduce;
*   But also: I have the impression (no fact) that more Maps increases the 
chance of crashing;
*   I have never seen GPS crash on search (Vista HCx, Etrex 30, GPSMAP 
62/66)
*   Find Addresses (Ctrl+Alt+A) will never crash (so: work-around);
*   I have also seen strange addresses found, which do not match my search 
criteria.
*   And – lol – I could reproduce a BaseCamp search which will take 10 
minutes to respond. Oeps, or was this a GPS search? Is this a search where 
BaseCamp will crash (impatience, no retry, no error handling) and GPS will try 
for 10 minutes and succeed???

 

My work-around:

Do not use BaseCamp for any Search. Not ever! I use my 

Re: [mkgmap-dev] Basecamp crashes on search if searching for many 2+ word phrases

[ankeric.osm]

Yes, this has been happening for a very long time (longer than my memory lane).

 

My “facts”:

*   Not possible to reproduce;
*   Sometimes it will take hours before the crash occurs. So, I don’t 
agree: “if a good search already has been executed (single word), then the 
crash rarely occurs”.
*   Long, long ago I have tested by uninstall all mkgmaps, which left over 
City Navigator 2007 (yes; 2007). And still: the error did occur. But harder to 
reproduce;
*   But also: I have the impression (no fact) that more Maps increases the 
chance of crashing;
*   I have never seen GPS crash on search (Vista HCx, Etrex 30, GPSMAP 
62/66)
*   Find Addresses (Ctrl+Alt+A) will never crash (so: work-around);
*   I have also seen strange addresses found, which do not match my search 
criteria.
*   And – lol – I could reproduce a BaseCamp search which will take 10 
minutes to respond. Oeps, or was this a GPS search? Is this a search where 
BaseCamp will crash (impatience, no retry, no error handling) and GPS will try 
for 10 minutes and succeed???

 

My work-around:

Do not use BaseCamp for any Search. Not ever! I use my smartphone + OsmAnd or 
Google search on second PC monitor.

I will only test a new version of BaseCamp and until now, it’s always not oké. 
Still not oké.

In BaseCamp I can only find an object, if I know where it is….

 

A BaseCamp crash is 99% harmless, but at 1% I lose information (in which case 
always (...) relevant information, so bad for my mood).

 

But I might have to apologize to Garmin.

I have always considered BaseCamp to be extreme bad software, but perhaps 
Garmin is not to blame???

 

If (but only “if”) you are gone investigate and mkgmap might be the cause, I 
could try “memory lane”.

I have posted several times on Garmin Vendor forum about searching and not 
finding or finding the wrong answers or crashing. 

I even might have found a way to reproduce ?

But these posting are all in Dutch language, so therefore: “If and only if”.

 

Sorry, too many “???”. 

But I assumed I had managed to suppress my - bad - memories

 

Eric (AnkEric)

 

From: mkgmap-dev  On Behalf Of Felix 
Hartmann
Sent: woensdag 2 juni 2021 11:20
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] Basecamp crashes on search if searching for many 2+ 
word phrases

 

Basecamp just closes 0-3 seconds after entering that term into the search bar. 
No warning, no error notice, nothing. Seems to have been happening a long time 
already. Okay this evening I will try to produce a map as small as possible 
that still crashes. I do not have much time now anymore - but will try if 
removing --split-name-index changes something. I kinda feel it has something to 
do with split-name-index.

 

On Wed, 2 Jun 2021 at 12:07, Gerd Petermann mailto:gpetermann_muenc...@hotmail.com> > wrote:

Hi Felix,

I couldn't reproduce the crash so far. Please provide a small map and exact 
instructions how to reproduce. What happens when BC crashes? Do you have some 
kind of report?

Gerd


Von: mkgmap-dev mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk> > im Auftrag von Felix Hartmann 
mailto:extremecar...@gmail.com> >
Gesendet: Mittwoch, 2. Juni 2021 10:16
An: Thomas Morgenstern; Development list for mkgmap
Betreff: Re: [mkgmap-dev] Basecamp crashes on search if searching for many 2+ 
word phrases

https://www.openstreetmap.org/node/3268115540
shop=hardware  | shop=trade  [0x2e01 resolution 24]
does not crash - it has a full address field. Maybe if we have address for a 
POI it does not crash?

I have to look but I think so far only entries without an address cause a 
crash. Also it does not crash if being nearby and only searching for one of the 
words of the entry thereby finding it.

On Wed, 2 Jun 2021 at 11:08, Felix Hartmann mailto:extremecar...@gmail.com>  >> wrote:
I just thought about it - could it be related to multi word street search? 
Maybe what works for multi word street search is not possible for old type POI 
search? So it is the multi word stuff that got introduced for roads that causes 
the crashes in Basecamp (not sure about what happens on devices - will check 
that out later).
--add-pois-to-areas 
--pois-to-areas-placement=entrance=main;entrance=yes;building=entrance;barrier=entrance
 --link-pois-to-ways --location-autofill=bounds,is_in,nearest and of coure 
--index are the most relevant to this thread options I am using.


On Wed, 2 Jun 2021 at 10:49, Felix Hartmann mailto:extremecar...@gmail.com>  >> wrote:
Even though Gerd also speaks German, I think its better to continue in English. 
I am quite sure that this is the same bug then. Your map does not crash because 
it find another POI first. I also sometimes have two POI for the same thing - 
one for finding it via a category POI search, the other for 

Re: [mkgmap-dev] How to search for osmid()=941762308

[ankeric.osm]

> you could try:
> mkgmap:mp_role=inner & osmId()=...

Almost correct but case sensitive: "osmId".

SEVERE (global): Error in style: Error: (inc/DEBUG_begin:150): Error: No 
function with name 'osmId()'

Correct syntax is " mkgmap:mp_role=inner & osmid()=...", which throws no Error 
message.

However, untagged inner way is not updated:

mkgmap:mp_role=inner & osmid()=941762308  { set landuse=forest }

Gerd: "multipolygon processing creates another way". 
Oké, but I was assuming my "inc/DEBUG_begin" is executed at the very beginning 
of mkgmap, before "polygons".

Also, tagged inner way is not updated:

mkgmap:mp_role=inner & osmid()=54108919   { set natural=water; delete 
landuse }

Only option I found for updating a - tagged - polygon:

landuse=* & osmid()=54108919   { set natural=water; delete landuse }

So, I will have to wait for a new dataset and tomorrow my Map will be correct. 
Which is 2 hours before deadline; -)

Case closed... thanks for help.

Eric (AnkEric)

-Original Message-
From: mkgmap-dev  On Behalf Of Ticker 
Berkin
Sent: woensdag 12 mei 2021 11:24
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] How to search for osmid()=941762308

Hi Eric

you could try:

  mkgmap:mp_role=inner & osmId()=...

but I suspect it won't work. generally inners are just cut out of outers and 
have no representation. The ways that make them will be there, but, having no 
tags, are dropped before style processing.

Ticker


On Wed, 2021-05-12 at 11:00 +0200, ankeric@gmail.com wrote:
> When an OSM-Mapper makes a mistake, I sometimes correct this Error (or 
> difference in opinion) by using mkgmap.
> 
> highway=* & osmid()=22689239  { set highway=track; set
> tracktype=grade1; delete service }
> 
> Which is OK, accepted by mkgmap syntax.
> 
> Yesterday I made a mistake as well: INNER in Multipolygon is untagged 
> and JOSM doesn't warn (no warning: "Untagged ways (1)").
> 
> Today I tried to correct my mistake:
> 
> osmid()=941762308  { set landuse=forest }
> 
> But, mkgmap doesn’t accept my correction:
> 
> SEVERE (global): Error in style: Error: (inc/DEBUG_begin:148):
> Invalid rule, expression cannot be indexed: osmid()=941762308
> 
> I was assuming osmid() is a Primary Key. 
> How to search for a Primary Key using mkgmap, If the way is also 
> untagged?
> 
> BTW, JOSM can find (search): id=941762308.
> 
> Eric (AnkEric)
> 
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] How to search for osmid()=941762308

[ankeric.osm]

When an OSM-Mapper makes a mistake, I sometimes correct this Error (or 
difference in opinion) by using mkgmap.

highway=* & osmid()=22689239  { set highway=track; set 
tracktype=grade1; delete service }

Which is OK, accepted by mkgmap syntax.

Yesterday I made a mistake as well: INNER in Multipolygon is untagged and JOSM 
doesn't warn (no warning: "Untagged ways (1)").

Today I tried to correct my mistake:

osmid()=941762308  { set landuse=forest }

But, mkgmap doesn’t accept my correction:

SEVERE (global): Error in style: Error: (inc/DEBUG_begin:148): Invalid rule, 
expression cannot be indexed: osmid()=941762308 

I was assuming osmid() is a Primary Key. 
How to search for a Primary Key using mkgmap, If the way is also untagged?

BTW, JOSM can find (search): id=941762308.

Eric (AnkEric)

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Please try branch check-precomp-sea

[ankeric.osm]

Hi Gerd,

I have reproduced the issue by using the "bad precomp-sea data":
- sea-latest.zip
- 254.705.164 bytes
- 30-03-2021 05:38

Mkgmap - Rev 4689:
merge the check-precomp-sea branch to do some basic plausibilty tests on 
precompiled sea data.
The new file sea-check.txt contains characters s (sea), m(mixed), and l(land). 
Each character represents one entry in the index file that comes with 
precompiled sea (sea.zip) with the expected result. Tiles near the coastline 
have m.
- If PrecompSeaGenerator is used to calculate the sea data and the index check 
fails a warning is printed and the program ends with rc -1.
- If mkgmap is used with a "dubious" sea.zip one or more messages about the 
problematic areas are written and the program stops with an ExitException
unless option --x-check-precomp-sea=0 is given before the first input file.
The index test is normally performed once for the whole planet, so it doesn't 
care about the actual tile boundaries. If e.g. only a part of Australia is 
flooded and you create a map for the UK you'll still see the errors.


Mkgmap (version 4689) will stop execution after 1 second ("ExitExceptions: 1") 
and write to mkgmap.log: (mkgmap.log, 2.154.367, 04-05-2021 17:28)


Mkgmap version 4689
Time started: Tue May 04 17:28:28 CEST 2021
SEVERE (SeaGenerator): G:\OSM_SPLITTER_Benelux\43010001.o5m: Precomp sea data 
seems to be wrong, land-only tile is flooded around 76.992188,103.007813, index 
key is 3571712_4784128