Re: [mkgmap-dev] Question on routing difference

[jan meisters]

Hi Gerd,

I just played with the routing prefs to see if I could change something ;-)

I´m using it like this: 
https://files.mkgmap.org.uk/download/557/OFM_default-BC_Mac.png 
<https://files.mkgmap.org.uk/download/557/OFM_default-BC_Mac.png>
And same here, checked toll-avoidance routes as preferred, unchecked over the 
primary.

Toll-avoidance should prefer bicycleroutes according to Minko.
I´ve unchecked long ago for some reason, don´t remember why and have to 
recompare.
But same as no path is routed there is no bicycleroute …

Jan


> Am 29.05.2022 um 16:17 schrieb Gerd Petermann 
> :
> 
> Hi jan,
> 
> maybe my routing profile for OFM bike is different?
> 
> Not sure what Minko recommends today. Mine says "Faster Time", Standard  
> Elevation Mode, only road type avoidance is for "Roll  Roads".
> When I remove the toll roads avoidance the route is different and follows the 
> major road.
> 
> Gerd
> 
> 
> ____
> Von: mkgmap-dev  im Auftrag von jan 
> meisters 
> Gesendet: Sonntag, 29. Mai 2022 16:07
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Question on routing difference
> 
> Hi Gerd,
> 
> here OFM lite gives the same unwanted result as OFM full :-(
> 
> Jan
> 
>> Am 29.05.2022 um 14:54 schrieb Gerd Petermann 
>> :
>> 
>> Hi Jan,
>> 
>> the artifical way would be a highway=residential, not path. Anyhow, I tried 
>> to reproduce the different routing results with the mentioned change in the 
>> OFM lite style
>> but found no difference, the wanted route is calculated for both versions.
>> 
>> Gerd
>> 
>> 
>> Von: mkgmap-dev  im Auftrag von Gerd 
>> Petermann 
>> Gesendet: Sonntag, 29. Mai 2022 14:10
>> An: Development list for mkgmap
>> Betreff: Re: [mkgmap-dev] Question on routing difference
>> 
>> Hi Jan,
>> 
>> not sure if you would find it with that id, since it would be an artificial 
>> way. Don't have time now, will look into this later.
>> 
>> Gerd
>> 
>> 
>> Von: mkgmap-dev  im Auftrag von jan 
>> meisters 
>> Gesendet: Sonntag, 29. Mai 2022 14:07
>> An: Development list for mkgmap
>> Betreff: Re: [mkgmap-dev] Question on routing difference
>> 
>> Hi Gerd,
>> 
>> do you mean another routable line?
>> All (routable) highways are echotagged in my style atm, but I can´t find 
>> 27463238 twice.
>> 
>> Jan
>> 
>> 
>>> Am 29.05.2022 um 09:16 schrieb Gerd Petermann 
>>> :
>>> 
>>> Hi Jan,
>>> 
>>> might be the oneway:bicycle=no on way 27463238 which can create an 
>>> additional path in the opposite direction.
>>> 
>>> Gerd
>>> 
>>> 
>>> Von: mkgmap-dev  im Auftrag von jan 
>>> meisters 
>>> Gesendet: Samstag, 28. Mai 2022 20:15
>>> An: Development list for mkgmap
>>> Betreff: [mkgmap-dev] Question on routing difference
>>> 
>>> Hi all,
>>> 
>>> I´m using an altered copy of the OFM style and therefore sometimes compare 
>>> the results.
>>> One routing difference I found I was able to lead back, but the cause I 
>>> don´t understand at all.
>>> 
>>> My test-route should prefer the small residential „Altengabengäßchen“ over 
>>> the primary „Viktoriastrasse“.
>>> Latest OFM does, my version not since I removed {add bicycle=yes} from this 
>>> line:
>>> highway=path & surface ~ 
>>> '(paved|asphalt|sett|concrete|paving_stones|paving_stones:30)' & access!=no 
>>> & access!=private & vehicle!=no { set highway=pedestrian; add bicycle=yes; 
>>> add motorcar=yes; }
>>> 
>>> But unfortunately there is no path or pedestrian in the test-route, nor is 
>>> it an option to use one.
>>> Anyone has an idea how this path>pedestrian rule could affect routing on 
>>> residential/primary?
>>> Same happens when I replay the change with the original OFM.
>>> 
>>> Up-to-date osm.pbf, route from BC and screenshots are here: 
>>> https://files.mkgmap.org.uk/download/556/test_route.zip
>>> 
>>> Thanks
>>> Jan
>>> ___
>>> 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 mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Question on routing difference

[jan meisters]

Hi Gerd,

here OFM lite gives the same unwanted result as OFM full :-(

Jan

> Am 29.05.2022 um 14:54 schrieb Gerd Petermann 
> :
> 
> Hi Jan,
> 
> the artifical way would be a highway=residential, not path. Anyhow, I tried 
> to reproduce the different routing results with the mentioned change in the 
> OFM lite style
> but found no difference, the wanted route is calculated for both versions.
> 
> Gerd
> 
> 
> Von: mkgmap-dev  im Auftrag von Gerd 
> Petermann 
> Gesendet: Sonntag, 29. Mai 2022 14:10
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Question on routing difference
> 
> Hi Jan,
> 
> not sure if you would find it with that id, since it would be an artificial 
> way. Don't have time now, will look into this later.
> 
> Gerd
> 
> ____
> Von: mkgmap-dev  im Auftrag von jan 
> meisters 
> Gesendet: Sonntag, 29. Mai 2022 14:07
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Question on routing difference
> 
> Hi Gerd,
> 
> do you mean another routable line?
> All (routable) highways are echotagged in my style atm, but I can´t find 
> 27463238 twice.
> 
> Jan
> 
> 
>> Am 29.05.2022 um 09:16 schrieb Gerd Petermann 
>> :
>> 
>> Hi Jan,
>> 
>> might be the oneway:bicycle=no on way 27463238 which can create an 
>> additional path in the opposite direction.
>> 
>> Gerd
>> 
>> 
>> Von: mkgmap-dev  im Auftrag von jan 
>> meisters 
>> Gesendet: Samstag, 28. Mai 2022 20:15
>> An: Development list for mkgmap
>> Betreff: [mkgmap-dev] Question on routing difference
>> 
>> Hi all,
>> 
>> I´m using an altered copy of the OFM style and therefore sometimes compare 
>> the results.
>> One routing difference I found I was able to lead back, but the cause I 
>> don´t understand at all.
>> 
>> My test-route should prefer the small residential „Altengabengäßchen“ over 
>> the primary „Viktoriastrasse“.
>> Latest OFM does, my version not since I removed {add bicycle=yes} from this 
>> line:
>> highway=path & surface ~ 
>> '(paved|asphalt|sett|concrete|paving_stones|paving_stones:30)' & access!=no 
>> & access!=private & vehicle!=no { set highway=pedestrian; add bicycle=yes; 
>> add motorcar=yes; }
>> 
>> But unfortunately there is no path or pedestrian in the test-route, nor is 
>> it an option to use one.
>> Anyone has an idea how this path>pedestrian rule could affect routing on 
>> residential/primary?
>> Same happens when I replay the change with the original OFM.
>> 
>> Up-to-date osm.pbf, route from BC and screenshots are here: 
>> https://files.mkgmap.org.uk/download/556/test_route.zip
>> 
>> Thanks
>> Jan
>> ___
>> 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

Re: [mkgmap-dev] Question on routing difference

[jan meisters]

Hi Gerd,

do you mean another routable line?
All (routable) highways are echotagged in my style atm, but I can´t find 
27463238 twice.

Jan


> Am 29.05.2022 um 09:16 schrieb Gerd Petermann 
> :
> 
> Hi Jan,
> 
> might be the oneway:bicycle=no on way 27463238 which can create an additional 
> path in the opposite direction.
> 
> Gerd
> 
> 
> Von: mkgmap-dev  im Auftrag von jan 
> meisters 
> Gesendet: Samstag, 28. Mai 2022 20:15
> An: Development list for mkgmap
> Betreff: [mkgmap-dev] Question on routing difference
> 
> Hi all,
> 
> I´m using an altered copy of the OFM style and therefore sometimes compare 
> the results.
> One routing difference I found I was able to lead back, but the cause I don´t 
> understand at all.
> 
> My test-route should prefer the small residential „Altengabengäßchen“ over 
> the primary „Viktoriastrasse“.
> Latest OFM does, my version not since I removed {add bicycle=yes} from this 
> line:
> highway=path & surface ~ 
> '(paved|asphalt|sett|concrete|paving_stones|paving_stones:30)' & access!=no & 
> access!=private & vehicle!=no { set highway=pedestrian; add bicycle=yes; add 
> motorcar=yes; }
> 
> But unfortunately there is no path or pedestrian in the test-route, nor is it 
> an option to use one.
> Anyone has an idea how this path>pedestrian rule could affect routing on 
> residential/primary?
> Same happens when I replay the change with the original OFM.
> 
> Up-to-date osm.pbf, route from BC and screenshots are here: 
> https://files.mkgmap.org.uk/download/556/test_route.zip
> 
> Thanks
> Jan
> ___
> 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] Question on routing difference

[jan meisters]

Hi all,

I´m using an altered copy of the OFM style and therefore sometimes compare the 
results.
One routing difference I found I was able to lead back, but the cause I don´t 
understand at all.

My test-route should prefer the small residential „Altengabengäßchen“ over the 
primary „Viktoriastrasse“.
Latest OFM does, my version not since I removed {add bicycle=yes} from this 
line:
highway=path & surface ~ 
'(paved|asphalt|sett|concrete|paving_stones|paving_stones:30)' & access!=no & 
access!=private & vehicle!=no { set highway=pedestrian; add bicycle=yes; add 
motorcar=yes; }

But unfortunately there is no path or pedestrian in the test-route, nor is it 
an option to use one.
Anyone has an idea how this path>pedestrian rule could affect routing on 
residential/primary?
Same happens when I replay the change with the original OFM.

Up-to-date osm.pbf, route from BC and screenshots are here: 
https://files.mkgmap.org.uk/download/556/test_route.zip

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

Re: [mkgmap-dev] Bad tile around East London / Greenwich

[jan meisters]

Hi Nick,

interesting! Indeed I have a lot transparent 1x1-POIs in my typ, but of course 
for stuff I only want in the index and not to be displayed.
As my map is only used by me with BaseCamp and my Oregon 450 I´m not aware of 
possible problems beside this setup.
I´ll keep an eye on it.

Jan

> Am 07.08.2021 um 17:17 schrieb nick :
> 
> Hi Jan
> 
> It wasn't so much the type number as the size of a poi bitmap.
> 
> In the 'olden' days Mapsource would allow pois with lengths and width 
> equalling zero. This would render them transparent, useful for names of 
> places.
> 
> However, Basecamp would not accept such pois and I think has a problem 
> displaying some pois with length and width  set to 1.
> 
> I'm glad it wasn't the typ file.
> 
> r
> 
> Nick
> 
> On 07/08/2021 14:59, jan meisters wrote:
>> Hi Gerd,
>> 
>> yes, 4805 renders correctly. Thanks!
>> 
>> @Nick: I tried without typ, but that made no difference. Do you remember the 
>> faulty POI?
>> 
>> Jan
>> 
>>> Am 07.08.2021 um 11:24 schrieb Gerd Petermann 
>>> :
>>> 
>>> Hi Jan,
>>> 
>>> I think r4805 fixes the problem. I've not analysed why the default style 
>>> doesn't show the problem. The routing data is very different.
>>> It seems that the OFM style produces a lot more restrictions.
>>> 
>>> Gerd
>>> 
>>> 
>>> Von: Gerd Petermann 
>>> Gesendet: Samstag, 7. August 2021 09:47
>>> An: Development list for mkgmap
>>> Betreff: AW: [mkgmap-dev] Bad tile around East London / Greenwich
>>> 
>>> Hi Jan,
>>> 
>>> I can reproduce the problem with the OFM full style. With the just released 
>>> r4804 I see this:
>>> SCHWERWIEGEND (global): Bad file format: e:\Jan\10700105.osm.pbf
>>> uk.me.parabola.imgfmt.FormatException: too many restrictions
>>>at uk.me.parabola.imgfmt.app.net.TableC.getOffsetSize(TableC.java:84)
>>>at 
>>> uk.me.parabola.imgfmt.app.net.TableC.propagateSizeBytes(TableC.java:88)
>>>at 
>>> uk.me.parabola.imgfmt.app.net.RouteCenter.updateOffsets(RouteCenter.java:87)
>>>at 
>>> uk.me.parabola.imgfmt.app.net.RouteCenter.write(RouteCenter.java:98)
>>>at uk.me.parabola.imgfmt.app.net.NODFile.writeNodes(NODFile.java:101)
>>>at uk.me.parabola.imgfmt.app.net.NODFile.write(NODFile.java:71)
>>>at 
>>> uk.me.parabola.mkgmap.build.MapBuilder.makeMap(MapBuilder.java:352)
>>>at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:114)
>>>at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:70)
>>>at uk.me.parabola.mkgmap.main.Main.lambda$1(Main.java:290)
>>>at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>>>at 
>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>>>at 
>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>>>at java.lang.Thread.run(Thread.java:748)
>>> 
>>> I think this problem is caused by an error in mkgmap, it seems to put too 
>>> many restrictions into one so called RouteCenter.
>>> Have to check the details...
>>> 
>>> Gerd
>>> 
>>> 
>>> Von: mkgmap-dev  im Auftrag von jan 
>>> meisters 
>>> Gesendet: Freitag, 6. August 2021 22:41
>>> An: Development list for mkgmap
>>> Betreff: Re: [mkgmap-dev] Bad tile around East London / Greenwich
>>> 
>>> Hi Gerd,
>>> 
>>> yes, but only on my own style:
>>> SCHWERWIEGEND (global): Bad file format: 10700105.osm.pbf
>>> 
>>> File uploaded 
>>> here<https://files.mkgmap.org.uk/download/517/10700105.osm.pbf>. It is 
>>> splitter-generated from a geofabrik great-britain-latest with 
>>> max-node=140.
>>> Splitter 615 and mkgmap 4802.
>>> 
>>> For my own and and the default I have the same splitter options:
>>> java -Xmx26000m -jar splitter.jar --output=pbf 
>>> --output-dir=/great_britain-splitter --max-nodes=140 --mapid=10750001 
>>> --geonames-file=PRECOMP/cities15000.txt 
>>> --polygon-file=ARGS/great_britain.poly DATA/great_britain-latest.osm.pbf
>>> 
>>> And mkgmap then:
>>> java -Xmx26000m -jar mkgmap.jar --output-dir=great_britain-output -c 
>>> ARGS/great_britain-HGT.args -c great_britain-splitter/te

Re: [mkgmap-dev] Bad tile around East London / Greenwich

[jan meisters]

Hi Gerd,

yes, 4805 renders correctly. Thanks!

@Nick: I tried without typ, but that made no difference. Do you remember the 
faulty POI?

Jan

> Am 07.08.2021 um 11:24 schrieb Gerd Petermann 
> :
> 
> Hi Jan,
> 
> I think r4805 fixes the problem. I've not analysed why the default style 
> doesn't show the problem. The routing data is very different.
> It seems that the OFM style produces a lot more restrictions.
> 
> Gerd
> 
> 
> Von: Gerd Petermann 
> Gesendet: Samstag, 7. August 2021 09:47
> An: Development list for mkgmap
> Betreff: AW: [mkgmap-dev] Bad tile around East London / Greenwich
> 
> Hi Jan,
> 
> I can reproduce the problem with the OFM full style. With the just released 
> r4804 I see this:
> SCHWERWIEGEND (global): Bad file format: e:\Jan\10700105.osm.pbf
> uk.me.parabola.imgfmt.FormatException: too many restrictions
>at uk.me.parabola.imgfmt.app.net.TableC.getOffsetSize(TableC.java:84)
>at 
> uk.me.parabola.imgfmt.app.net.TableC.propagateSizeBytes(TableC.java:88)
>at 
> uk.me.parabola.imgfmt.app.net.RouteCenter.updateOffsets(RouteCenter.java:87)
>at uk.me.parabola.imgfmt.app.net.RouteCenter.write(RouteCenter.java:98)
>at uk.me.parabola.imgfmt.app.net.NODFile.writeNodes(NODFile.java:101)
>at uk.me.parabola.imgfmt.app.net.NODFile.write(NODFile.java:71)
>at uk.me.parabola.mkgmap.build.MapBuilder.makeMap(MapBuilder.java:352)
>at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:114)
>at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:70)
>at uk.me.parabola.mkgmap.main.Main.lambda$1(Main.java:290)
>at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>at java.lang.Thread.run(Thread.java:748)
> 
> I think this problem is caused by an error in mkgmap, it seems to put too 
> many restrictions into one so called RouteCenter.
> Have to check the details...
> 
> Gerd
> 
> 
> Von: mkgmap-dev  im Auftrag von jan 
> meisters 
> Gesendet: Freitag, 6. August 2021 22:41
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Bad tile around East London / Greenwich
> 
> Hi Gerd,
> 
> yes, but only on my own style:
> SCHWERWIEGEND (global): Bad file format: 10700105.osm.pbf
> 
> File uploaded 
> here<https://files.mkgmap.org.uk/download/517/10700105.osm.pbf>. It is 
> splitter-generated from a geofabrik great-britain-latest with 
> max-node=140.
> Splitter 615 and mkgmap 4802.
> 
> For my own and and the default I have the same splitter options:
> java -Xmx26000m -jar splitter.jar --output=pbf 
> --output-dir=/great_britain-splitter --max-nodes=140 --mapid=10750001 
> --geonames-file=PRECOMP/cities15000.txt 
> --polygon-file=ARGS/great_britain.poly DATA/great_britain-latest.osm.pbf
> 
> And mkgmap then:
> java -Xmx26000m -jar mkgmap.jar --output-dir=great_britain-output -c 
> ARGS/great_britain-HGT.args -c great_britain-splitter/template.args 
> ARGS/1.txt
> 
> The mkgmap ARGS for my style are:
> family-id: 10700
> product-id: 1
> draw-priority: 30
> series-name: Great_Britain-HGT
> family-name: Great_Britain-HGT
> description: Great_Britain-HGT
> copyright-message: openstreetmap.org<http://openstreetmap.org> | 
> earthexplorer.usgs.gov<http://earthexplorer.usgs.gov> | 
> viewfinderpanoramas.org<http://viewfinderpanoramas.org> | 
> openfietsmap.nl<http://openfietsmap.nl>
> area-name: Great_Britain
> country-name: Great_Britain
> country-abbr: Great_Britain
> style-file: Styles
> overview-mapname: 1070
> precomp-sea: PRECOMP/sea-latest.zip
> generate-sea: land-tag=natural=background
> bounds: PRECOMP/bounds-latest.zip
> location-autofill: is_in,nearest
> housenumbers
> split-name-index
> tdbfile
> latin1
> name-tag-list: name,name:de,int_name,place_name
> code-page: 1252
> dem: HGT_NASADEM_Europe
> dem-dists: 3314,4971,6628,13256,29826
> overview-dem-dist=89478
> show-profiles: 1
> merge-lines
> road-name-config=examples/roadNameConfig.txt
> add-pois-to-areas
> pois-to-areas-placement
> add-pois-to-lines
> link-pois-to-ways
> poi-excl-index=0x3200-0x331f
> nearby-poi-rules=*/named:5,*/unnamed:10,0x2b07:50,0x2f00-0x2f03:50,0x2f04-0x2f09:25,0x2f0a-0x2f0b:25,0x2f0c:50,0x2f0d-0x2f0f:25,0x2f10-0x2f16:50,0x2f17-0x2f18:25,0x2f19:50,0x2f1a-0x2f1f:50,0x3200-0x331f:50,0x13700-0x13702:50,0x13703-0x13707:25,0x13708-0x13709:50,0x1370a-0x1370f:50

Re: [mkgmap-dev] Bad tile around East London / Greenwich

[jan meisters]

Hi Gerd,

yes, but only on my own style:
SCHWERWIEGEND (global): Bad file format: 10700105.osm.pbf

File uploaded here <https://files.mkgmap.org.uk/download/517/10700105.osm.pbf>. 
It is splitter-generated from a geofabrik great-britain-latest with 
max-node=140.
Splitter 615 and mkgmap 4802.

For my own and and the default I have the same splitter options:
java -Xmx26000m -jar splitter.jar --output=pbf 
--output-dir=/great_britain-splitter --max-nodes=140 --mapid=10750001 
--geonames-file=PRECOMP/cities15000.txt --polygon-file=ARGS/great_britain.poly 
DATA/great_britain-latest.osm.pbf

And mkgmap then:
java -Xmx26000m -jar mkgmap.jar --output-dir=great_britain-output -c 
ARGS/great_britain-HGT.args -c great_britain-splitter/template.args 
ARGS/1.txt

The mkgmap ARGS for my style are:
family-id: 10700
product-id: 1
draw-priority: 30
series-name: Great_Britain-HGT
family-name: Great_Britain-HGT
description: Great_Britain-HGT
copyright-message: openstreetmap.org | earthexplorer.usgs.gov | 
viewfinderpanoramas.org | openfietsmap.nl
area-name: Great_Britain
country-name: Great_Britain
country-abbr: Great_Britain
style-file: Styles
overview-mapname: 1070
precomp-sea: PRECOMP/sea-latest.zip
generate-sea: land-tag=natural=background
bounds: PRECOMP/bounds-latest.zip
location-autofill: is_in,nearest
housenumbers
split-name-index
tdbfile
latin1
name-tag-list: name,name:de,int_name,place_name
code-page: 1252
dem: HGT_NASADEM_Europe
dem-dists: 3314,4971,6628,13256,29826
overview-dem-dist=89478
show-profiles: 1
merge-lines
road-name-config=examples/roadNameConfig.txt
add-pois-to-areas
pois-to-areas-placement
add-pois-to-lines
link-pois-to-ways
poi-excl-index=0x3200-0x331f
nearby-poi-rules=*/named:5,*/unnamed:10,0x2b07:50,0x2f00-0x2f03:50,0x2f04-0x2f09:25,0x2f0a-0x2f0b:25,0x2f0c:50,0x2f0d-0x2f0f:25,0x2f10-0x2f16:50,0x2f17-0x2f18:25,0x2f19:50,0x2f1a-0x2f1f:50,0x3200-0x331f:50,0x13700-0x13702:50,0x13703-0x13707:25,0x13708-0x13709:50,0x1370a-0x1370f:50
min-size-polygon: 4
polygon-size-limits=16:2, 14:0
preserve-element-order
keep-going
route
index

And mkgmap ARGS for default:
family-id: 10750
product-id: 1
draw-priority: 30
series-name: Great_Britain-default
family-name: Great_Britain-default
description: Great_Britain-default
area-name: Great_Britain
country-name: Great_Britain
country-abbr: Great_Britain
style-file: examples/styles/default
overview-mapname: 1075
precomp-sea: PRECOMP/sea-latest.zip
generate-sea: land-tag=natural=background
bounds: PRECOMP/bounds-latest.zip
# location-autofill: is_in,nearest
# housenumbers
# split-name-index
# tdbfile
# latin1
# name-tag-list: name,name:de,int_name,place_name
code-page: 1252
# dem: HGT_NASADEM_Europe
# dem-dists: 3314,4971,6628,13256,29826
# overview-dem-dist=89478
# show-profiles: 1
# merge-lines
# road-name-config=examples/roadNameConfig.txt
add-pois-to-areas
# pois-to-areas-placement
add-pois-to-lines
link-pois-to-ways
# min-size-polygon: 4
# polygon-size-limits=16:2, 14:0
# preserve-element-order
keep-going
route
index



> Am 06.08.2021 um 19:58 schrieb Gerd Petermann 
> :
> 
> Hi Jan,
> 
> Any error message from mkgmap?
> I can try to reproduce if you upload the input osm file to 
> https://files.mkgmap.org.uk/
> (or post another download link)
> and the options that you use.
> 
> 
> Gerd
> 
> ____
> Von: mkgmap-dev  im Auftrag von jan 
> meisters 
> Gesendet: Freitag, 6. August 2021 19:35
> An: Development list for mkgmap
> Betreff: [mkgmap-dev] Bad tile around East London / Greenwich
> 
> Hi all,
> 
> since some time my map has a bad tile around East London (Greenwich).
> I´ve checked earlier revisions of splitter and mkgmap, and decreased 
> splitter´s max-nodes - without success.
> 
> Problem seems to be in my style, which is based on OpenFietsMap. With the 
> original OFM-style the error is rendered as well, but not with the mkgmap 
> default style.
> But I´ve got no clue where to look for the mistake -  anyone has got a hint 
> for me?
> 
> https://files.mkgmap.org.uk/download/516/bad_tile-east_london.jpg
> 
> Jan
> 
> ___
> 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] Bad tile around East London / Greenwich

[jan meisters]

Hi all,

since some time my map has a bad tile around East London (Greenwich).
I´ve checked earlier revisions of splitter and mkgmap, and decreased splitter´s 
max-nodes - without success.

Problem seems to be in my style, which is based on OpenFietsMap. With the 
original OFM-style the error is rendered as well, but not with the mkgmap 
default style.
But I´ve got no clue where to look for the mistake -  anyone has got a hint for 
me?

https://files.mkgmap.org.uk/download/516/bad_tile-east_london.jpg

Jan

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

Re: [mkgmap-dev] is_in with own Tags?

[jan meisters]

Hi Ticker,

thanks - but the rules are still not asking for is_in(stadium-wth-sport).
If I insert is_in(sport) it´s still for is_in(stadium) & is_in(sport) - an own 
(sport) must match.

I have to give up my idea so far.
If even you has no suggestion how to write the above - what should I do.
Maybe it is simply undefinable, as you said before.

Nevertheless, the negation-syntax unifies the handling of POIs and area2pois :-)

Jan


> Am 22.02.2021 um 11:33 schrieb Ticker Berkin :
> 
> Hi Jan
> 
> To suppress a point POI if is_in an area/polygon that may also generate
> one:
> 
> leisure=stadium & sport=swimming & mkgmap:area2poi!=* &
>  is_in(leisure, stadium, in_or_on)=false &
>  is_in(leisure, water_park, in_or_on)=false &
>  is_in(leisure, swimming_pool, in_or_on)=false
>  {...stadium swim...} [0x...]
> 
> and repeat for the other types
> 
> To suppress one derived from a polygon if also in another:
> 
> leisure=stadium & sport=swimming & mkgmap:area2poi=* &
>  is_in(leisure,
> water_park, in_or_on)=false &
>  is_in(leisure, swimming_pool,
> in_or_on)=false
>  {...stadium swim...} [0x...]
> 
> etc. ie similar to above but remove the test for is_in own type
> 
> There is a problem with this however; if the centre/placement point of
> the outer polygon falls in_or_on the inner, neither will generate a
> POI!
> 
> Ticker
> 
> On Mon, 2021-02-22 at 10:52 +0100, jan meisters wrote:
>> Hi Ticker,
>> 
>> thank you - yes, that explains a lot of my troubles.
>> 
>> But - if I got you right: isn`t this what I need?
>>  For an area2poi POI, it is almost certain that it is_in(its own
>> type)
>>  but you can exclude it if is_in(the other types).
>> Do you have an example for the mentioned exclusion?
>> 
>> Concerning deletion: it seemed to be easier to delete unwanted POIs
>> while testing, but indeed I prefer to handle this by tagging later.
>> For sure I want to miss as little information as possible, but
>> distinguish the available - I dropped the corresponding naming
>> actions for simplification, and the mopup at the end also ;-)
>> 
>> Jan
>> 
>> 
>>> Am 21.02.2021 um 22:32 schrieb Ticker Berkin <
>>> rwb-mkg...@jagit.co.uk>:
>>> 
>>> Hi Jan
>>> 
>>> I don't think you'll be able to do what you hope for.
>>> 
>>> Each possible POI comes either:
>>> a) direct from a point
>>> b) from a polygon if --add-pois-to-areas, setting
>>> mkgmap:area2poi=true
>>>  This happens regardless of any rules etc.
>>> 
>>> All you can do in the points rule processing is choose to display a
>>> POI
>>> or not.
>>> 
>>> For a direct POI, you can test if is_in any of the types of polygon
>>> and
>>> suppress it if you choose.
>>> 
>>> For an area2poi POI, it is almost certain that it is_in(its own
>>> type)
>>> but you can exclude it if is_in(the other types).
>>> 
>>> There is no is_in() test for being in a polygon (of some type) that
>>> is
>>> in another polygon (of same or any other type). 
>>> 
>>> It is clearer to apply these tests to the POI generation rule
>>> rather
>>> than {delete} the tag to be tested. For {delete} to work, it has to
>>> be
>>> done before the rule that might generated the [POI]. It is obscure
>>> to
>>> show the {delete} afterwards, even though, with careful rule
>>> ordering,
>>> the same effect could be achieved. 
>>> 
>>> Does this make sense?
>>> 
>>> Ticker
>>> 
>>> On Sun, 2021-02-21 at 18:04 +0100, jan meisters wrote:
>>>> (Still problems with attachments. Now with link)
>>>> 
>>>> Hi Ticker,
>>>> 
>>>> I want to ask for relevant swimmings, one after another, and
>>>> after
>>>> every rule exclude further swimmings inside aleady matched areas.
>>>> In the end the style should dismiss e.g. leisure=swimming_pools
>>>> which
>>>> lay in a (leisure=stadium & sport=swimming) already matched:
>>>> 
>>>> 1. leisure=stadium & sport=swimming {name '${name}
>>>> (stadium
>>>> swim)‘ | '(stadium swim)'} [0x2d09 resolution 24]
>>>>sport=swimming & is_in(leisure,stadium,in_or_on)=true &
>>>> is_in(sport,swimming,in_or_on)=true {delete sport}
>>>> 2. leisure=water_park & sport=swimming {name '${name}
>>>> (waterpark swim

Re: [mkgmap-dev] is_in with own Tags?

[jan meisters]

Hi Ticker,

thank you - yes, that explains a lot of my troubles.

But - if I got you right: isn`t this what I need?
For an area2poi POI, it is almost certain that it is_in(its own type)
but you can exclude it if is_in(the other types).
Do you have an example for the mentioned exclusion?

Concerning deletion: it seemed to be easier to delete unwanted POIs while 
testing, but indeed I prefer to handle this by tagging later.
For sure I want to miss as little information as possible, but distinguish the 
available - I dropped the corresponding naming actions for simplification, and 
the mopup at the end also ;-)

Jan


> Am 21.02.2021 um 22:32 schrieb Ticker Berkin :
> 
> Hi Jan
> 
> I don't think you'll be able to do what you hope for.
> 
> Each possible POI comes either:
> a) direct from a point
> b) from a polygon if --add-pois-to-areas, setting mkgmap:area2poi=true
>   This happens regardless of any rules etc.
> 
> All you can do in the points rule processing is choose to display a POI
> or not.
> 
> For a direct POI, you can test if is_in any of the types of polygon and
> suppress it if you choose.
> 
> For an area2poi POI, it is almost certain that it is_in(its own type)
> but you can exclude it if is_in(the other types).
> 
> There is no is_in() test for being in a polygon (of some type) that is
> in another polygon (of same or any other type). 
> 
> It is clearer to apply these tests to the POI generation rule rather
> than {delete} the tag to be tested. For {delete} to work, it has to be
> done before the rule that might generated the [POI]. It is obscure to
> show the {delete} afterwards, even though, with careful rule ordering,
> the same effect could be achieved. 
> 
> Does this make sense?
> 
> Ticker
> 
> On Sun, 2021-02-21 at 18:04 +0100, jan meisters wrote:
>> (Still problems with attachments. Now with link)
>> 
>> Hi Ticker,
>> 
>> I want to ask for relevant swimmings, one after another, and after
>> every rule exclude further swimmings inside aleady matched areas.
>> In the end the style should dismiss e.g. leisure=swimming_pools which
>> lay in a (leisure=stadium & sport=swimming) already matched:
>> 
>> 1.   leisure=stadium & sport=swimming {name '${name} (stadium
>> swim)‘ | '(stadium swim)'} [0x2d09 resolution 24]
>>  sport=swimming & is_in(leisure,stadium,in_or_on)=true &
>> is_in(sport,swimming,in_or_on)=true {delete sport}
>> 2.   leisure=water_park & sport=swimming {name '${name}
>> (waterpark swim)‘ | '(waterpark swim)'} [0x2d09 resolution 24]
>>  sport=swimming & is_in(leisure, water_park,in_or_on)=true &
>> is_in(sport,swimming,in_or_on)=true {delete sport}
>> 3.   leisure=swimming_pool & sport=swimming {name '${name} (pool
>> swim)‘ | ‚(pool swim)'} [0x2d09 resolution 24]
>>  sport=swimming & is_in(leisure, swimming_pool,in_or_on)=true &
>> is_in(sport,swimming,in_or_on)=true {delete sport}
>> 4.   …
>> 
>> With the above ruleset I have correct results for nodes so far, but
>> not for polygons.
>> The is_in-rule seems to lack the epression of is_n(leisure=stadium &
>> sport=swimming), instead matches a polygons own swimming as well -
>> what I don´t want.
>> But I´ve got no clue how to write it.
>> 
>> In swim.osm the surrounding left stadium has swimming, the right one
>> not. Inside both stadium, water_park and sports_centre as area and
>> poi. (See http://files.mkgmap.org.uk/detail/500 for the following
>> screenshots)
>> 
>> Above ruleset gives this: 1-result.jpg
>> In left stadium pois for stadium/swim (area, area inside, poi
>> inside), nothing else: correct.
>> In right stadium pois for all swim inside except for the areas:
>> wrong.
>> 
>> What I expect is this: 2-expected.jpg
>> Left as before, but In the right pois for all swim inside including
>> areas.
>> 
>> Hope I made it clearer
>> Jan
>> 
>> 
>>> Am 21.02.2021 um 13:01 schrieb Ticker Berkin <
>>> rwb-mkg...@jagit.co.uk>:
>>> 
>>> Hi Jan
>>> 
>>> I'm slightly confused as to what you are trying to do here when you
>>> say
>>> it works for nodes but not polygons.
>>> 
>>> After you've output a POI from the first rule what are you trying
>>> to
>>> do?
>>> 
>>> Ticker
>>> 
>>> On Sun, 2021-02-21 at 10:42 +0100, jan meisters wrote:
>>>> Hi Gerd,
>>>> 
>>>> my first impression didn´t get trough further test.
>>>> 
>>>> This works for nodes, but not for p

Re: [mkgmap-dev] is_in with own Tags?

[jan meisters]

(Still problems with attachments. Now with link)

Hi Ticker,

I want to ask for relevant swimmings, one after another, and after every rule 
exclude further swimmings inside aleady matched areas.
In the end the style should dismiss e.g. leisure=swimming_pools which lay in a 
(leisure=stadium & sport=swimming) already matched:

1.  leisure=stadium & sport=swimming {name '${name} (stadium swim)‘ | 
'(stadium swim)'} [0x2d09 resolution 24]
sport=swimming & is_in(leisure,stadium,in_or_on)=true & 
is_in(sport,swimming,in_or_on)=true {delete sport}
2.  leisure=water_park & sport=swimming {name '${name} (waterpark swim)‘ | 
'(waterpark swim)'} [0x2d09 resolution 24]
sport=swimming & is_in(leisure, water_park,in_or_on)=true & 
is_in(sport,swimming,in_or_on)=true {delete sport}
3.  leisure=swimming_pool & sport=swimming {name '${name} (pool swim)‘ | 
‚(pool swim)'} [0x2d09 resolution 24]
sport=swimming & is_in(leisure, swimming_pool,in_or_on)=true & 
is_in(sport,swimming,in_or_on)=true {delete sport}
4.  …

With the above ruleset I have correct results for nodes so far, but not for 
polygons.
The is_in-rule seems to lack the epression of is_n(leisure=stadium & 
sport=swimming), instead matches a polygons own swimming as well - what I don´t 
want.
But I´ve got no clue how to write it.

In swim.osm the surrounding left stadium has swimming, the right one not. 
Inside both stadium, water_park and sports_centre as area and poi. (See 
http://files.mkgmap.org.uk/detail/500 for the following screenshots)

Above ruleset gives this: 1-result.jpg
In left stadium pois for stadium/swim (area, area inside, poi inside), nothing 
else: correct.
In right stadium pois for all swim inside except for the areas: wrong.

What I expect is this: 2-expected.jpg
Left as before, but In the right pois for all swim inside including areas.

Hope I made it clearer
Jan


> Am 21.02.2021 um 13:01 schrieb Ticker Berkin  <mailto:rwb-mkg...@jagit.co.uk>>:
> 
> Hi Jan
> 
> I'm slightly confused as to what you are trying to do here when you say
> it works for nodes but not polygons.
> 
> After you've output a POI from the first rule what are you trying to
> do?
> 
> Ticker
> 
> On Sun, 2021-02-21 at 10:42 +0100, jan meisters wrote:
>> Hi Gerd,
>> 
>> my first impression didn´t get trough further test.
>> 
>> This works for nodes, but not for polygons:
>>  leisure=stadium & sport=swimming [0x2d09 resolution 24]
>>  sport=swimming & is_in(leisure,stadium,in_or_on)=true &
>> is_in(sport,swimming,in_or_on)=true {delete sport}
>> 
>> It matches it´s own swimming tag as well, not only when stadium is
>> given.
>> Tried various spellings/brackets, but I can´t get it to work for
>> stadium and swimming as a combination only.
>> I guess we don´t have a syntax for this?
>> 
>> Attached a small example.
>> 
>> Jan
>> 
>> 
>>> Am 16.02.2021 um 18:28 schrieb jan meisters >> <mailto:jan_...@gmx.net>>:
>>> 
>>> Hi Gerd,
>>> 
>>> so easy - that works!
>>> Thanks for helping me out
>>> Jan
>>> 
>>>> Am 16.02.2021 um 17:44 schrieb Gerd Petermann <
>>>> gpetermann_muenc...@hotmail.com <mailto:gpetermann_muenc...@hotmail.com>>:
>>>> 
>>>> Hi Jan,
>>>> 
>>>> is_in(leisure,park,...) & is_in(sport,swimming,...)
>>>> should work.
>>>> 
>>>> Gerd
>>>> 
>>>> 
>>>> Von: mkgmap-dev >>> <mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>> im
>>>> Auftrag von jan meisters mailto:jan_...@gmx.net>>
>>>> Gesendet: Dienstag, 16. Februar 2021 17:31
>>>> An: Development list for mkgmap
>>>> Betreff: Re: [mkgmap-dev] is_in with own Tags?
>>>> 
>>>> Hi Joris,
>>>> 
>>>> thanks for stating - I guessed something like that.
>>>> 
>>>> What I want is to is_in for a tag-combination, e.g. leisure=park
>>>> & sport=swimming.
>>>> I have a poi-rule for park first and further want to
>>>> exclude swimmings inside matching polygons.
>>>> 
>>>> Do I have another option to define the combination so that it can
>>>> be seen by is_in?
>>>> 
>>>> Thanks
>>>> Jan
>>>> 
>>>>> Am 16.02.2021 um 14:48 schrieb Joris Bo >>>> <mailto:jori...@hotmail.com>>:
>>>>> 
>>>>> Hi Jan
>>>>> 
>>>>&g

Re: [mkgmap-dev] is_in with own Tags?

[jan meisters]

Hi Gerd,

my first impression didn´t get trough further test.

This works for nodes, but not for polygons:
leisure=stadium & sport=swimming [0x2d09 resolution 24]
sport=swimming & is_in(leisure,stadium,in_or_on)=true & 
is_in(sport,swimming,in_or_on)=true {delete sport}

It matches it´s own swimming tag as well, not only when stadium is given.
Tried various spellings/brackets, but I can´t get it to work for stadium and 
swimming as a combination only.
I guess we don´t have a syntax for this?

Attached a small example.

Jan


swim.osm
Description: application/osm



> Am 16.02.2021 um 18:28 schrieb jan meisters :
> 
> Hi Gerd,
> 
> so easy - that works!
> Thanks for helping me out
> Jan
> 
>> Am 16.02.2021 um 17:44 schrieb Gerd Petermann 
>> :
>> 
>> Hi Jan,
>> 
>> is_in(leisure,park,...) & is_in(sport,swimming,...)
>> should work.
>> 
>> Gerd
>> 
>> 
>> Von: mkgmap-dev  im Auftrag von jan 
>> meisters 
>> Gesendet: Dienstag, 16. Februar 2021 17:31
>> An: Development list for mkgmap
>> Betreff: Re: [mkgmap-dev] is_in with own Tags?
>> 
>> Hi Joris,
>> 
>> thanks for stating - I guessed something like that.
>> 
>> What I want is to is_in for a tag-combination, e.g. leisure=park & 
>> sport=swimming.
>> I have a poi-rule for park first and further want to exclude 
>> swimmings inside matching polygons.
>> 
>> Do I have another option to define the combination so that it can be seen by 
>> is_in?
>> 
>> Thanks
>> Jan
>> 
>>> Am 16.02.2021 um 14:48 schrieb Joris Bo :
>>> 
>>> Hi Jan
>>> 
>>> As far as i understood this function really checks the polygons around the 
>>> poi to check if the poi-coordinates are located within the polygon 
>>> specified.
>>> It can not check variables because they don't have an outline.
>>> 
>>> 
>>> 
>>> Met vriendelijke groeten,
>>> 
>>> Joris Bo
>>> jori...@hotmail.com
>>> 
>>> -Oorspronkelijk bericht-
>>> Van: mkgmap-dev  Namens jan meisters
>>> Verzonden: dinsdag 16 februari 2021 14:12
>>> Aan: Development list for mkgmap 
>>> Onderwerp: [mkgmap-dev] is_in with own Tags?
>>> 
>>> Hi all,
>>> 
>>> I try to use is_in to fetch pois inside own invented tags, e.g.:
>>> 
>>> leisure=park {add processed=yes} [0x2c06 resolution 24 continue 
>>> with_actions]
>>> leisure=swimming_pool & is_in(processed,yes,in_or_on)=true {delete 
>>> leisure}
>>> 
>>> This fails, however „is_in(leisure,park,in_or_on)=true“ works in the 
>>> example.
>>> Could someone explain where I´m wrong?
>>> 
>>> Thanks
>>> Jan
>>> ___
>>> mkgmap-dev mailing list
>>> mkgmap-dev@lists.mkgmap.org.uk
>>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>>> ___
>>> mkgmap-dev mailing list
>>> mkgmap-dev@lists.mkgmap.org.uk
>>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>> 
>> ___
>> mkgmap-dev mailing list
>> mkgmap-dev@lists.mkgmap.org.uk
>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>> ___
>> mkgmap-dev mailing list
>> mkgmap-dev@lists.mkgmap.org.uk
>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> 
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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

Re: [mkgmap-dev] is_in with own Tags?

[jan meisters]

Hi Gerd,

so easy - that works!
Thanks for helping me out
Jan

> Am 16.02.2021 um 17:44 schrieb Gerd Petermann 
> :
> 
> Hi Jan,
> 
> is_in(leisure,park,...) & is_in(sport,swimming,...)
> should work.
> 
> Gerd
> 
> ____
> Von: mkgmap-dev  im Auftrag von jan 
> meisters 
> Gesendet: Dienstag, 16. Februar 2021 17:31
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] is_in with own Tags?
> 
> Hi Joris,
> 
> thanks for stating - I guessed something like that.
> 
> What I want is to is_in for a tag-combination, e.g. leisure=park & 
> sport=swimming.
> I have a poi-rule for park first and further want to exclude 
> swimmings inside matching polygons.
> 
> Do I have another option to define the combination so that it can be seen by 
> is_in?
> 
> Thanks
> Jan
> 
>> Am 16.02.2021 um 14:48 schrieb Joris Bo :
>> 
>> Hi Jan
>> 
>> As far as i understood this function really checks the polygons around the 
>> poi to check if the poi-coordinates are located within the polygon specified.
>> It can not check variables because they don't have an outline.
>> 
>> 
>> 
>> Met vriendelijke groeten,
>> 
>> Joris Bo
>> jori...@hotmail.com
>> 
>> -Oorspronkelijk bericht-
>> Van: mkgmap-dev  Namens jan meisters
>> Verzonden: dinsdag 16 februari 2021 14:12
>> Aan: Development list for mkgmap 
>> Onderwerp: [mkgmap-dev] is_in with own Tags?
>> 
>> Hi all,
>> 
>> I try to use is_in to fetch pois inside own invented tags, e.g.:
>> 
>>  leisure=park {add processed=yes} [0x2c06 resolution 24 continue 
>> with_actions]
>>  leisure=swimming_pool & is_in(processed,yes,in_or_on)=true {delete 
>> leisure}
>> 
>> This fails, however „is_in(leisure,park,in_or_on)=true“ works in the example.
>> Could someone explain where I´m wrong?
>> 
>> Thanks
>> Jan
>> ___
>> mkgmap-dev mailing list
>> mkgmap-dev@lists.mkgmap.org.uk
>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>> ___
>> mkgmap-dev mailing list
>> mkgmap-dev@lists.mkgmap.org.uk
>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> 
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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

Re: [mkgmap-dev] is_in with own Tags?

[jan meisters]

Hi Joris,

thanks for stating - I guessed something like that.

What I want is to is_in for a tag-combination, e.g. leisure=park & 
sport=swimming.
I have a poi-rule for park first and further want to exclude swimmings 
inside matching polygons.

Do I have another option to define the combination so that it can be seen by 
is_in?

Thanks
Jan

> Am 16.02.2021 um 14:48 schrieb Joris Bo :
> 
> Hi Jan
> 
> As far as i understood this function really checks the polygons around the 
> poi to check if the poi-coordinates are located within the polygon specified.
> It can not check variables because they don't have an outline.
> 
> 
> 
> Met vriendelijke groeten,
> 
> Joris Bo
> jori...@hotmail.com
> 
> -Oorspronkelijk bericht-
> Van: mkgmap-dev  Namens jan meisters
> Verzonden: dinsdag 16 februari 2021 14:12
> Aan: Development list for mkgmap 
> Onderwerp: [mkgmap-dev] is_in with own Tags?
> 
> Hi all,
> 
> I try to use is_in to fetch pois inside own invented tags, e.g.:
> 
>   leisure=park {add processed=yes} [0x2c06 resolution 24 continue 
> with_actions]
>   leisure=swimming_pool & is_in(processed,yes,in_or_on)=true {delete 
> leisure}
> 
> This fails, however „is_in(leisure,park,in_or_on)=true“ works in the example.
> Could someone explain where I´m wrong?
> 
> Thanks
> Jan
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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

[mkgmap-dev] is_in with own Tags?

[jan meisters]

Hi all,

I try to use is_in to fetch pois inside own invented tags, e.g.:

leisure=park {add processed=yes} [0x2c06 resolution 24 continue 
with_actions]
leisure=swimming_pool & is_in(processed,yes,in_or_on)=true {delete 
leisure}

This fails, however „is_in(leisure,park,in_or_on)=true“ works in the example.
Could someone explain where I´m wrong?

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

Re: [mkgmap-dev] Pending changes

[jan meisters]

Hi Ticker,

in fact 3200 - 3f1f strictly follow their given resolution value - other than 
e.g. 2a-2f, which only appear at kind of 24+, no matter what resolution is 
given.
Even if both ranges are styled to resolution 24: 2a-2f will always appear a bit 
later.
I suspect that´s what Gerd found to be confusing.

Jan


> Am 12.02.2021 um 09:46 schrieb Ticker Berkin :
> 
> Hi Gerd
> 
> The "points" barriers use 0x3200 and I only see these when I
> "overzoom". I think I configured the device Map Detail levels and Text
> sizes to get it how I wanted.
> 
> I find them useful when walking and sometimes useful for choosing an
> end-point for car navigation or seeing why a route hasn't been chosen.
> 
> "lines" barriers (wall/ditch/etc) again I find useful when walking.
> 
> Either of these can commented out by users making their own style
> starting from default. When I started, the first thing I had to remove
> were all the low-level administrative boundaries, but I think it right
> that they are in the default style. 
> 
> I'd rather not start on other changes until this lot is out of the way.
> 
> Ticker
> 
> On Thu, 2021-02-11 at 15:27 +, Gerd Petermann wrote:
>> Hi Ticker,
>> 
>> while you are at it: I see lots of rather confusing texts like "gate"
>> or "lift_gate" popping up in the map on my Oregon. I think they might
>> be useful for mappers but they are not very useful for the normal
>> user. Maybe it is only on my device but I don't see any need for
>> this.
>> 
>> Gerd
>> 
>> 
>> Von: mkgmap-dev  im Auftrag
>> von Ticker Berkin 
>> Gesendet: Donnerstag, 11. Februar 2021 15:57
>> An: Development list for mkgmap
>> Betreff: Re: [mkgmap-dev] Pending changes
>> 
>> Hi all
>> 
>> I've re-made this set of changes, along with a few improvements that
>> I've gathered over the last 6 months. Following list numbering is the
>> same as original patch, but include some [extra] notes + new items at
>> the end.
>> 
>> Relevant threads:
>> http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2020q3/031375.html
>> http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2020q3/031424.html
>> 
>> 1/ Sometimes charges for using a pedestrian highway are expressed as
>> a
>> fee rather than a toll, so pick this up in mkgmap:toll.
>> 
>> 2/ Show bridges using type 0x10107. With the mapnik addition, these
>> look good for narrow highways, but might not show for wide
>> representations like motorways.
>> 
>> 3/ Where it is likely that bits of highway might not be connected to
>> the road/path system, use mkgmap:set_unconnected_type and
>> mkgmap:set_semi_connected_type to stop the NET/NOD rather than
>> relying
>> on NETnoNOD (now disabled) and --check-routing-island-len=+ve, which
>> is
>> being suspected of causing problems on some devices and BaseCamp.
>> 
>> [extra] In all cases where unconnected/semi-connected changes are
>> mentioned, this only applies to lines not derived from an
>> original/OSM
>> standard highway.
>> 
>> 4/ Quote some filter subst strings that contain spaces - no actual
>> effect but clearer and safer.
>> 
>> 5/ Have line for leisure=track even if area.
>> 
>> 6/ Change the type for tracks/raceways etc from 0x30, which doesn't
>> show on BaseCamp or MapSource, to 0x2a.
>> 
>> 7/ For piers, if 'unconnecting', use marine type 0x1040c
>> (Obstruction:
>> Pier or Jetty) instead of footway.
>> 
>> 8/ Change type for the various barriers from 0x17, which doesn't show
>> on BaseCamp to 0x2b, see:
>> http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2020q1/030348.html
>> 
>> 9/ Consider natural=cliff a barrier.
>> 
>> 10/ Add motorway[_link] roundabouts (yes, some do exist).
>> 
>> 11/ Unquote some numbers - no actual effect.
>> 
>> 12/ Tweak some road speeds.
>> [extra] A few more tweaked.
>> 
>> 13/ Use 0x09 (high-speed ramp) for road class 4 links
>> 
>> 14/ Add footway around car parks if 'connecting'.
>> [extra] This change is disabled.
>> 
>> 15/ Disable coastline. For a long time the tag was suppressed by the
>> Sea processing and it adds little to the map.
>> 
>> 16/ Improve railway platform names and suppress footway if not
>> 'connecting'.
>> 
>> 17/ Show disused:railway in the same way as railway=disused.
>> 
>> 18/ Have cable_car, gondola, funicular as routable, by default with a
>> toll and pedestrian only.
>> 
>> 19/ Show "Course of old Railway", unless a highway has taken over the
>> way (for you Eric, but I like it as well).
>> [extra] This change is disabled
>> 
>> 20/ Speed up car ferries.
>> 
>> 21/ A few other layout/space fixes.
>> 
>> Additional changes:
>> 
>> 22/ motorroad=yes just sets mkgmap:fast_road, which generally
>> increases
>> the speed/class of the highway and decreases the resolution
>> 
>> 23/ natural=landslide like other barriers (eg cliff)
>> 
>> 24/ Don't generate (routable) line for highway=unclassified &
>> area=yes;
>> there are many instances in OSM where this is used to draw a polygon
>> around a complex junction.
>> 
>> 25/ Change the 

Re: [mkgmap-dev] Multipolygon Role Understanding

[jan meisters]

Hi Gerd,

yes, that works for me as described. As I understand, due to consecutive 
processing: nameless leisure gone, next matched?
Another work_around I found by just changing the outer role to an inner.
Both indicates imho more likely a mistagging.

I´d like to have an overpass query to find similar examples - if anyone has an 
idea: appreciated ;-)

Jan

> Am 10.02.2021 um 23:13 schrieb Gerd Petermann 
> :
> 
> Hi all,
> 
> sorry, the style file is OK. I just tried with the (locally) corrected MP 
> (removed the leisure tag) and with that the name "Naturfreibad Sankt Märgen" 
> is shown in the map.
> I think the multipolygon code removes all tags from the outer way which also 
> appear in the MP. The remaining tags
> name=Naturfreibad Sankt Märgen
> opening_hours=Jun-Sep: Mo-Su 09:00-18:00
> wheelchair=limited
> are ignored by the default style.
> 
> The behaviour is intended, but in fact a bit confusing.
> 
> Gerd
> 
> 
> Von: mkgmap-dev  im Auftrag von Gerd 
> Petermann 
> Gesendet: Mittwoch, 10. Februar 2021 23:03
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Multipolygon Role Understanding
> 
> Hi Jan,
> 
> I think the multipolygon describes the landuse, the outer way describes the 
> leisure. It makes no sense to have both tags on the MP.
> Reg. the missing "Naturfreibad Sankt Märgen":
> The default style doesn't use the name of the leisure, neither for the 
> polygon nor for the POI. Not sure why. I would have expected that inc/name 
> does that.
> 
> Gerd
> 
> 
> Von: mkgmap-dev  im Auftrag von jan 
> meisters 
> Gesendet: Mittwoch, 10. Februar 2021 21:11
> An: mkgmap-dev@lists.mkgmap.org.uk
> Betreff: [mkgmap-dev] Multipolygon Role Understanding
> 
> Hi all,
> 
> with my limited multipolygon knowledge I stumbled on missing poi tags here:
> https://www.openstreetmap.org/relation/4077717
> 
> The multipolygon is tagged more limited than the outer role.
> mkgmap renders the mp-tags, but drops the more useful outer tags (name etc.).
> This useful it´s rendered on openstreetmap, but I can´t get it with mkgmap.
> Tried default style and others, even OsmAnd (in OffRoad.jar) - all fail.
> 
> So I wonder how or at all I could style the desired display in mkgmap.
> Of course the mp itself might be wrong - don`t know - but then I suspect a 
> lot of them ;-/
> 
> Jan
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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

[mkgmap-dev] Multipolygon Role Understanding

[jan meisters]

Hi all,

with my limited multipolygon knowledge I stumbled on missing poi tags here:
https://www.openstreetmap.org/relation/4077717

The multipolygon is tagged more limited than the outer role.
mkgmap renders the mp-tags, but drops the more useful outer tags (name etc.).
This useful it´s rendered on openstreetmap, but I can´t get it with mkgmap.
Tried default style and others, even OsmAnd (in OffRoad.jar) - all fail.

So I wonder how or at all I could style the desired display in mkgmap.
Of course the mp itself might be wrong - don`t know - but then I suspect a lot 
of them ;-/

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

Re: [mkgmap-dev] Device Crash Analysis

[jan meisters]

@Felix: I tried demo-mode to run along the way before posting, but couldn´t 
reproduce the crash.


@Ticker: „Lock on road“ is always turned off / set to NO.
Bridges I put on 0x2b and continue with_actions, that´s it for lines:
(highway=* | railway=*) & bridge=* & bridge!=no & bridge!=proposed & 
area!=yes [0x2b resolution 23 continue with_actions]

Though, bridge:name=* I later use to hide some names.
Then in points mkgmap:line2poi combined with bridges=* to get pois about some 
restrictions.
But neither rule seems to be affected by the example.

In polygons
area:highway=bridge | man_made=bridge | building=bridge [0x10105 
default_name="bridge" resolution 23]

matches the bridge-areas east and west of the crash point.
On site it seemed to crash exactly on the edge of western bridge-area eastbound.
The western is missing the layer-tag of the eastern - but I don´t retrieve 
layer in this context anyway.

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

[mkgmap-dev] Device Crash Analysis

[jan meisters]

I recently experienced a crash of my Oregon when passing this street 
s 
treet, and reproduced it several 
times.
The device ran in tracking mode, no routing involved.

I suspected the bridges on both sides, but found nothing suspicious concerning 
my style in OSM. Later simulations on device and BC gave no errors.
Unfortunately it´s not nearby, so I can´t easily recheck on-site.

What other options do I have for further analysis?

Thanks
Jan___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Routing problem on Garmin Oregon/edge with default style (and other styles)

[jan meisters]

@ Joris:  <http://cornerbug.com/html/mkgmap/mkgmap-r4373.zip>mkgmap- 
<http://cornerbug.com/html/mkgmap/mkgmap-r4373.zip>r4373 
<http://cornerbug.com/html/mkgmap/mkgmap-r4373.zip>

@ Felix: retested my map based on your .osm.pbf with same result: No crashes, 
no recalculations.
But still no pink routing on (northbound) Castillo de Alarcon.
(Sorry, mixed up streetnames: in both tests northbound had no pink, westbound 
had)


> Am 27.06.2020 um 12:54 schrieb Joris Bo  <mailto:jori...@hotmail.com>>:
> 
> Hi
>  
> Is there a online repository of compiled mkgmap versions?
> I found an answer form Gerd that ‘you can create one form svn, but I don’t 
> have those skills.
>  
> I am looking for versions between
> r4323 (29-10-2019)  still ok
> r4386 (8-12-2019)problem persist
>  
> @Felix Yes, I always used the most recent default style also with the older 
> mkgmap versions for the tes.
>  
> Kind regards
> Joris
>  
>  
>  
> Van: mkgmap-dev  <mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>> Namens jan meisters
> Verzonden: zaterdag 27 juni 2020 11:42
> Aan: Development list for mkgmap  <mailto:mkgmap-dev@lists.mkgmap.org.uk>>
> Onderwerp: Re: [mkgmap-dev] Routing problem on Garmin Oregon/edge with 
> default style (and other styles)
>  
> Tested on Oregon 450 without crash: runs until destination.
>  
> Map used is from 04/2020, created with mkgmap-r4479 using my own (pure cycle) 
> style.
> Therefore routing still set to bicycle (fastest / avoid unaved), but as well 
> no crash with ATV.
>  
> Nevertheless, here Calle Castillo de Ponferrada isn`t pink while simulation, 
> but Calle Castillo de Alarcón is.
>  
>  
> Am 26.06.2020 um 14:39 schrieb Felix Hartmann  <mailto:extremecar...@gmail.com>>:
>  
> https://www.openstreetmap.org/way/2786/history#map=15/40.4752/-3.9411 
> <https://www.openstreetmap.org/way/2786/history#map=15/40.4752/-3.9411> 
>  
>  
> Trying to route along this route crashes the GPS device - not sure what i 
> going on here. In demo mode - just set location to: 
> https://www.openstreetmap.org/way/2786/history#map=18/40.48063/-3.94040 
> <https://www.openstreetmap.org/way/2786/history#map=18/40.48063/-3.94040>
>  
> and route to:
>  
> https://www.openstreetmap.org/way/2786/history#map=19/40.46711/-3.94385 
> <https://www.openstreetmap.org/way/2786/history#map=19/40.46711/-3.94385> 
> (Calle Castillo de Ponferrada)
>  
>  The route will first be normal pink, however as soon as it goes onto the 
> Calle Castillo de Alarcón
> it will keep on routing - but the pink colour is gone. Then after maybe half 
> of the road it stops routing and asks to recalculate (which will be in a loop 
> if you click yes).
>  
>  
> map produced with. 
> start /low /b /wait java -jar -XX:+AggressiveHeap -XX:StringTableSize=103 
> -Xms15000M -Xmx29000M C:\openmtbmap\mkgmap.jar --max-jobs=8 
> --order-by-decreasing-area  --code-page=1252 
> --add-boundary-nodes-at-admin-boundaries  --nsis --index --levels="0:24, 
> 1:23, 2:22, 3:21, 4:20, 5:19, 6:18" --overview-levels="7:17, 8:16, 9:15, 
> 10:14, 11:13, 12:12" --add-pois-to-areas 
> --pois-to-areas-placement=entrance=main;entrance=yes;building=entrance;barrier=entrance
>  --reduce-point-density=3.4 --reduce-point-density-polygon=6 
> --add-boundary-nodes-at-admin-boundaries=2 
> --poi-excl-index=0x6405,0x4316,0x2f00 --cycle-map --check-roundabout-flares 
> --ignore-fixme-values --housenumbers 
> --road-name-config=C:\openmtbmap\openmtbmap_svn\roadNameConfig.txt 
> --split-name-index --link-pois-to-ways --ignore-turn-restrictions 
> --polygon-size-limits="24:16, 23:14, 22:12, 21:11, 20:10, 19:9, 18:8, 17:7, 
> 16:6, 15:5, 14:4, 13:3, 12:2, 11:0, 10:0" --description=omtb_es 
> --show-profiles=1  --location-autofill=bounds,is_in,nearest   --route 
> --country-abbr=es --country-name=spain --mapname=6413 --family-id=6413 
> --product-id=1 --series-name=omtb_spain_26.06.2020 
> --family-name=mtb_es_26.06.2020 --tdbfile --overview-mapname=mapsetc 
> --keep-going --area-name="spain_26.06.2020_omtb" 
> D:\openmtbmap\maps\64130028.osm.pbf   1>NUL 2>NUL
>  
>  
> Routing setup on device as:
> ATV/Off Road Driving
> Minimize Distance
> No Avoidances 
>  
> but I think this does not matter.
>  
>  
> I have uploaded the broken tile/map here:
> https://openmtbmap.org/maps.7z <https://openmtbmap.org/maps.7z>
> the osm.pbf for that tile is:
> https://openmtbmap.org/64130028.osm.pbf 
> <https://openmtbmap.org/64130028.osm.pbf>
>  
>  
> I have no real clue what is happeni

Re: [mkgmap-dev] Routing problem on Garmin Oregon/edge with default style (and other styles)

[jan meisters]

Tested on Oregon 450 without crash: runs until destination.

Map used is from 04/2020, created with mkgmap-r4479 using my own (pure cycle) 
style.
Therefore routing still set to bicycle (fastest / avoid unaved), but as well no 
crash with ATV.

Nevertheless, here Calle Castillo de Ponferrada isn`t pink while simulation, 
but Calle Castillo de Alarcón is.


> Am 26.06.2020 um 14:39 schrieb Felix Hartmann :
> 
> https://www.openstreetmap.org/way/2786/history#map=15/40.4752/-3.9411 
>  
> 
> 
> Trying to route along this route crashes the GPS device - not sure what i 
> going on here. In demo mode - just set location to: 
> https://www.openstreetmap.org/way/2786/history#map=18/40.48063/-3.94040 
> 
> 
> and route to:
> 
> https://www.openstreetmap.org/way/2786/history#map=19/40.46711/-3.94385 
>  
> (Calle Castillo de Ponferrada)
> 
>  The route will first be normal pink, however as soon as it goes onto the 
> Calle Castillo de Alarcón
> it will keep on routing - but the pink colour is gone. Then after maybe half 
> of the road it stops routing and asks to recalculate (which will be in a loop 
> if you click yes).
> 
> 
> map produced with. 
> start /low /b /wait java -jar -XX:+AggressiveHeap -XX:StringTableSize=103 
> -Xms15000M -Xmx29000M C:\openmtbmap\mkgmap.jar --max-jobs=8 
> --order-by-decreasing-area  --code-page=1252 
> --add-boundary-nodes-at-admin-boundaries  --nsis --index --levels="0:24, 
> 1:23, 2:22, 3:21, 4:20, 5:19, 6:18" --overview-levels="7:17, 8:16, 9:15, 
> 10:14, 11:13, 12:12" --add-pois-to-areas 
> --pois-to-areas-placement=entrance=main;entrance=yes;building=entrance;barrier=entrance
>  --reduce-point-density=3.4 --reduce-point-density-polygon=6 
> --add-boundary-nodes-at-admin-boundaries=2 
> --poi-excl-index=0x6405,0x4316,0x2f00 --cycle-map --check-roundabout-flares 
> --ignore-fixme-values --housenumbers 
> --road-name-config=C:\openmtbmap\openmtbmap_svn\roadNameConfig.txt 
> --split-name-index --link-pois-to-ways --ignore-turn-restrictions 
> --polygon-size-limits="24:16, 23:14, 22:12, 21:11, 20:10, 19:9, 18:8, 17:7, 
> 16:6, 15:5, 14:4, 13:3, 12:2, 11:0, 10:0" --description=omtb_es 
> --show-profiles=1  --location-autofill=bounds,is_in,nearest   --route 
> --country-abbr=es --country-name=spain --mapname=6413 --family-id=6413 
> --product-id=1 --series-name=omtb_spain_26.06.2020 
> --family-name=mtb_es_26.06.2020 --tdbfile --overview-mapname=mapsetc 
> --keep-going --area-name="spain_26.06.2020_omtb" 
> D:\openmtbmap\maps\64130028.osm.pbf   1>NUL 2>NUL
> 
> 
> Routing setup on device as:
> ATV/Off Road Driving
> Minimize Distance
> No Avoidances 
> 
> but I think this does not matter.
> 
> 
> I have uploaded the broken tile/map here:
> https://openmtbmap.org/maps.7z 
> the osm.pbf for that tile is:
> https://openmtbmap.org/64130028.osm.pbf 
> 
> 
> 
> I have no real clue what is happening here. If you set highway=residential 
> from road_class=0 / road_speed=2 to say 1 / 1 crash is even earlier.
> 
> I cannot find anything special looking at the road with GPSMapedit. Garmin 
> Edge devices supposedly crash too - not sure about other devices.
> 
> 
> Felix
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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

Re: [mkgmap-dev] nearby POIs

[jan meisters]

Hi Gerd,

thanks, I see.
The given example can easily be handled with is_in anyway.

Jan

> Am 03.05.2020 um 08:19 schrieb Gerd Petermann 
> :
> 
> Hi Jan,
> 
> yes, the data structure used for this new option is too simple when multiple 
> unnamed or equally named POI at very different locations are handled.
> The first processed POI is stored and for all further POI the position is 
> compared with that first. The algo is not able to handle multiple clouds like 
> in your example.
> 
> @Mike: My approach would be to collect all POI, even those which appear at 
> the same location, in a list. This list would be reduced with a single method 
> call  in StyledConverter.end().
> Small disadvantage: You cannot log the node details.
> I'll work on this idea, if you prefer another just go ahead and we can 
> compare the solutions.
> 
> Gerd
> 
> ____
> Von: mkgmap-dev  im Auftrag von jan 
> meisters 
> Gesendet: Samstag, 2. Mai 2020 22:28
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] nearby POIs
> 
> Hi Mike, hi Gerd,
> 
> thanks for the nearby option, I like the new way to unclutter the map.
> 
> To my args-file i´ve added:
> nearby-poi-rules=*/named:10,*/unnamed:30,0x2f00-0x2f1f:30,0x3200-0x331f:50,0x13700-0x1370d:30
> 
> A lot of the pois seem to be reduced (deleted) as expected, but I stumbled on 
> tourism=picnic_site and leisure=picnic_table here:
> https://www.openstreetmap.org/way/498671746
> https://www.openstreetmap.org/way/108892873
> 
> These 2 polygon tourism=picnic_site contain picnic pois, tourism in the one 
> and leisure in the other.
> My rule combines the pois in 0x2f0b:
> tourism=picnic_site | leisure=picnic_table [0x2f0b resolution 24]
> 
> As long as tourism and leisure are collected in one poi, both poi will not be 
> reduced.
> If separated to different pois, tourism is reduced, leisure not.
> I can´t get the option to work on both.
> 
> Regards
> Jan
> 
> 
>> Am 29.04.2020 um 18:06 schrieb Gerd Petermann 
>> :
>> 
>> Hi Mike,
>> 
>> OK, did not see this line
>> fileRules.addAll(Arrays.asList(rules));
>> 
>> So, I think I'll commit the patch tomorrow if nobody else suggests changes.
>> 
>> Gerd
>> 
>> 
>> Von: mkgmap-dev  im Auftrag von Mike 
>> Baggaley 
>> Gesendet: Mittwoch, 29. April 2020 17:52
>> An: 'Development list for mkgmap'
>> Betreff: Re: [mkgmap-dev] nearby POIs
>> 
>> Hi Gerd,
>> 
>> I've replaced the trim statements with replaceAll in the attached updated
>> patch. Having thought a bit more about caching the rules, I've realised in
>> the multithreaded environment, there would need to be object locks and
>> synchronisation, which would be unnecessarily complicated.
>> 
>> Regarding the two options - I had 30 odd rules in my command line, so the
>> config file is better for me, but I expect that most users will probably
>> just use one or two rules. Your range suggestion has allowed me to reduce
>> the number of rules to about 25. The config file option doesn't override the
>> inline option; if both are provided then both sets of rules are applied -
>> hence I don't think the documentation needs changing.
>> 
>> Regards,
>> Mike
>> 
>> -Original Message-
>> From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com]
>> Sent: 29 April 2020 07:28
>> To: 'Development list for mkgmap' 
>> Subject: Re: [mkgmap-dev] nearby POIs
>> 
>> Hi Mike,
>> 
>> regarding error handling I think we can wait for someone to complain. Each
>> solution has its pros and cons.
>> regarding option handling:
>> - I have no idea what users do. It is possible to create very different maps
>> with a single execution of mkgmap. I can't think of any good reason to do
>> this, but I also see no way to find out if anybody does. I presume that many
>> users don't read this list.
>> - If you see a simple solution to cache the results which works fine with
>> multiple threads using different options go ahead.
>> - When I suggested --nearby-poi-rules-config=filename I thought that is
>> should replace --nearby-poi-rules. Having both options simply complicates
>> everything. If you think that it is unlikely to have more than two rules we
>> should better remove --nearby-poi-rules-config=filename, else it should be
>> documented that --nearby-poi-rules-config=filename overwrites
>> --nearby-poi-rules.  Sorry for suggesting it in the first place.
>> - all those trim() statements in combination wit

Re: [mkgmap-dev] nearby POIs

[jan meisters]

Hi Mike, hi Gerd,

thanks for the nearby option, I like the new way to unclutter the map.

To my args-file i´ve added:
nearby-poi-rules=*/named:10,*/unnamed:30,0x2f00-0x2f1f:30,0x3200-0x331f:50,0x13700-0x1370d:30

A lot of the pois seem to be reduced (deleted) as expected, but I stumbled on 
tourism=picnic_site and leisure=picnic_table here:
https://www.openstreetmap.org/way/498671746
https://www.openstreetmap.org/way/108892873

These 2 polygon tourism=picnic_site contain picnic pois, tourism in the one and 
leisure in the other.
My rule combines the pois in 0x2f0b:
tourism=picnic_site | leisure=picnic_table [0x2f0b resolution 24]

As long as tourism and leisure are collected in one poi, both poi will not be 
reduced.
If separated to different pois, tourism is reduced, leisure not.
I can´t get the option to work on both.

Regards
Jan


> Am 29.04.2020 um 18:06 schrieb Gerd Petermann 
> :
> 
> Hi Mike,
> 
> OK, did not see this line
>  fileRules.addAll(Arrays.asList(rules));
> 
> So, I think I'll commit the patch tomorrow if nobody else suggests changes.
> 
> Gerd
> 
> 
> Von: mkgmap-dev  im Auftrag von Mike 
> Baggaley 
> Gesendet: Mittwoch, 29. April 2020 17:52
> An: 'Development list for mkgmap'
> Betreff: Re: [mkgmap-dev] nearby POIs
> 
> Hi Gerd,
> 
> I've replaced the trim statements with replaceAll in the attached updated
> patch. Having thought a bit more about caching the rules, I've realised in
> the multithreaded environment, there would need to be object locks and
> synchronisation, which would be unnecessarily complicated.
> 
> Regarding the two options - I had 30 odd rules in my command line, so the
> config file is better for me, but I expect that most users will probably
> just use one or two rules. Your range suggestion has allowed me to reduce
> the number of rules to about 25. The config file option doesn't override the
> inline option; if both are provided then both sets of rules are applied -
> hence I don't think the documentation needs changing.
> 
> Regards,
> Mike
> 
> -Original Message-
> From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com]
> Sent: 29 April 2020 07:28
> To: 'Development list for mkgmap' 
> Subject: Re: [mkgmap-dev] nearby POIs
> 
> Hi Mike,
> 
> regarding error handling I think we can wait for someone to complain. Each
> solution has its pros and cons.
> regarding option handling:
> - I have no idea what users do. It is possible to create very different maps
> with a single execution of mkgmap. I can't think of any good reason to do
> this, but I also see no way to find out if anybody does. I presume that many
> users don't read this list.
> - If you see a simple solution to cache the results which works fine with
> multiple threads using different options go ahead.
> - When I suggested --nearby-poi-rules-config=filename I thought that is
> should replace --nearby-poi-rules. Having both options simply complicates
> everything. If you think that it is unlikely to have more than two rules we
> should better remove --nearby-poi-rules-config=filename, else it should be
> documented that --nearby-poi-rules-config=filename overwrites
> --nearby-poi-rules.  Sorry for suggesting it in the first place.
> - all those trim() statements in combination with substring() look error
> prone. If I got that right you could use rule.replaceAll("\\s+", "") once to
> remove all whitespace characters?
> 
> Gerd
> 
> 
> Von: mkgmap-dev  im Auftrag von Mike
> Baggaley 
> Gesendet: Dienstag, 28. April 2020 22:06
> An: 'Development list for mkgmap'
> Betreff: Re: [mkgmap-dev] nearby POIs
> 
> Hi Gerd, please find attached an updated patch that allows for # comments
> either as whole lines or as ends of a line. It also allows whitespace
> between the components of the rules.
> 
> At the moment, if an error is found in a rule, this is reported as an error
> and that rule is ignored. This does result in duplicated error messages, one
> from each tile. I'm happy to change this to stop processing if you think
> that is better. I'm not keen on ignoring all rules if an error is found in a
> rule. If the rules file is not found then this will also just report an
> error and continue. Perhaps this one at least would be better if it caused
> termination?
> 
> I did think about loading the rules at the beginning, prior to processing
> the tiles, but realised this would break the 'option before tile' convention
> which allows different options to be passed to each tile (does anyone do
> this for anything other than the description?). It would be pretty
> straightforward to cache the options and resulting rules and if the options
> are the same for the next tile, use the cached rules instead of
> reprocessing. What do you think?
> 
> Regards,
> Mike
> 
> -Original Message-
> From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com]
> Sent: 28 April 2020 09:21
> To: 'Development list for mkgmap' 

Re: [mkgmap-dev] Resolutions...

[jan meisters]

Hi Nick,

pois from 0x2900 to 0x311f are only visible on resolution „24+".
Means you have to „overzoom“ deeper into resolution 24 to see them.

This behaviour is not related to mkgmap, it seems to be a limitiation by Garmin 
to avoid cluttering of maps with these pois, as they contain most indexed items 
like shops, restaurants, etc. Only exception are airports on 0x2f04.

To have these pois appearing earlier I haven´t found another solution yet than 
to "double“ wanted pois.
In your example:
church=* [0x3202 resolution 23 continue]
church=* [0x2c02 resolution 24]

Disadvantage: Basecamp (4.6.3/Mac) not only shows the pois on wanted 
resolution, but also lists these doubles in search („All Pois“ only)
On device (at least my Oregon450) the range 0x3200-0x330f doesn´t appear in 
searches, but is visible as expected.

Jan


> Am 10.03.2020 um 13:39 schrieb nwillink :
> 
> Hi 
> 
> Can anyone tell me what exactly the '-' in after resolutions means.
> 
> I plotted a church resolution 21-23  only to find it does not include
> resolution 23.
> 
> Somewhere I read that only the resolutions between the numbers are plotted.
> 
> If that is the case what does 23-24 mean ? What resolution is there between
> 23 and 24
> 
> What happens with resolution 23-23 ?
> 
> Does 23-24 mean only level 23
> Is 24-23 different from 23-24?
> 
> The manual does not seem to tackle this issue.
> 
> btw
> 
> Have noticed that Basecamp/Mapsource only plots 0x2c poi range at level 24
> 
> So the following might never occur in some GPS devices is except at
> resolution 24 
> 
> 0x2c02 [resolution 21 ]
> 
> This seems to affect :
> 
> viewpoints,churches,castles, schools,amusement parks etc
> 
> Regards
> 
> Nick
> 
> 
> 
> 
> 
> --
> Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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

Re: [mkgmap-dev] Garmin Lines Visibility

[jan meisters]

Hi Steph,

looks like we have the same workflow - with a mistake in mine.
So I remembered the Header size option of TypViewer, which is always defaulted 
to 91: switched to 110 (or higher) the problem is gone.

Jan

> Am 11.02.2020 um 16:49 schrieb Steph :
> 
> Hi Jan,
> 
> I use a .txt type file from TypViewer.
> In my points file, I got "amenity=taxi [0x13703 resolution 24]".
> No problem to process with mkgmap and this .txt. If I load the generated .typ 
> in TypViewer, all seems correct.
> 
> Regards.
> 
> Steph
> 
> Le 11/02/2020 à 14:35, jan meisters a écrit :
>> I played with 3-digit points and found mkgmap not being able to compile a 
>> Typ file containing these.
>> E.g. points with code 0x137/00-0x137/09 appear in the compiled typ as points 
>> with the same code 0x001/00 for all of them.
>> My input file is a txt-file prepared with TypViewer, with which I can save 
>> such a file as Typ correctly.
>> I never stumbled upon this before, but it might be known to others.
>> Is there a workaround, or a mistake by me?
>> Jan
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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

Re: [mkgmap-dev] Garmin Lines Visibility

[jan meisters]

I played with 3-digit points and found mkgmap not being able to compile a Typ 
file containing these.
E.g. points with code 0x137/00-0x137/09 appear in the compiled typ as points 
with the same code 0x001/00 for all of them.

My input file is a txt-file prepared with TypViewer, with which I can save such 
a file as Typ correctly.

I never stumbled upon this before, but it might be known to others.
Is there a workaround, or a mistake by me?

Jan


> Am 04.02.2020 um 14:29 schrieb Pinns UK :
> 
> Personally I have not come across line types > 130 although I have seen 135 
> as a poi in a city navigator map
> 
> On 04/02/2020 13:18, Gerd Petermann wrote:
>> Hi Nick,
>> 
>> not sure about the limit of extended types. 0x1f for the lowest byte, but 
>> mkgmap doesn't seem to limit the higher byte. So maybe 1ff1f.
>> I think I'll add code to perform the same type checks for *.mp files as for 
>> style files.
>> 
>> Gerd
>> 
>> 
>> Von: mkgmap-dev  im Auftrag von 
>> Pinns UK 
>> Gesendet: Dienstag, 4. Februar 2020 11:48
>> An: mkgmap-dev@lists.mkgmap.org.uk
>> Betreff: Re: [mkgmap-dev] Garmin Lines Visibility
>> 
>> Hi Gerd
>> 
>> Yes, I used a mp file - no error message was shown
>> 
>> I presume extended line types have a maximum of 13F1f?
>> 
>> Regards
>> 
>> Nick
>> 
>> On 04/02/2020 10:44, Gerd Petermann wrote:
>>> Hi Nick,
>>> 
>>> yes, 0x3f is also coded as limit in mkgmap. It complains when you use a 
>>> higher line type like 0x57 in the style:
>>> Error: invalid type 0x57 for POLYLINE in style file lines, line 121
>>> 
>>> Maybe it doesn't complain with polish (*.mp) input?
>>> 
>>> Gerd
>>> 
>>> 
>>> Von: mkgmap-dev  im Auftrag von 
>>> nwillink 
>>> Gesendet: Dienstag, 4. Februar 2020 11:29
>>> An: mkgmap-dev@lists.mkgmap.org.uk
>>> Betreff: [mkgmap-dev] Garmin Lines Visibility
>>> 
>>> Hi All
>>> 
>>> Following from Jorics' response to Gerd  have done some more research
>>> regarding lines on Basecamp:
>>> 
>>> *Lines with non extended types*
>>> 
>>> it seems that the highest line type is 0x3F
>>> 
>>> Strangely Mapsource shows a repeat of lines 0 to 3F starting from 0x40
>>> This looks like  mkgmap allows such types but Garmin seems to set a 'flag'
>>> of some kind and regards 0x40 as 0x0 etc
>>> 
>>> Not Visible : 0x17 , 0x 2c , 0x30 - 0x3F
>>> 
>>> Not customisable Labels: 0x20 - 0x22
>>> 
>>> *Extended Lines*
>>> 
>>> Not Visible : 0x10200 - 102FF ,
>>>1080e ,
>>>0812 - 1081f,
>>>   10b05-10b1f ,
>>>  12e00 -anything higher
>>> 
>>> 
>>> 
>>> No Labels : 0x10906 - 1091f , 10b02-10b04
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> --
>>> Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html
>>> ___
>>> mkgmap-dev mailing list
>>> mkgmap-dev@lists.mkgmap.org.uk
>>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>>> ___
>>> mkgmap-dev mailing list
>>> mkgmap-dev@lists.mkgmap.org.uk
>>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>> ___
>> mkgmap-dev mailing list
>> mkgmap-dev@lists.mkgmap.org.uk
>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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

Re: [mkgmap-dev] [mkgmap-svn] Commit r4439: merge from trunk r4437

[jan meisters]

After running r4439 I found a new folder in my working directory named e/, inside some gpx files.What is the need of these? Attached examples result from rendering RegBez. Koeln.Jan<>
Am 06.02.2020 um 17:44 schrieb svn commit :Version mkgmap-r4439 was committed by gerd on Thu, 06 Feb 2020BRANCH: is-inmerge from trunk r4437http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap=4439___mkgmap-svn mailing listTo unsubscribe send an mail to mkgmap-svn-le...@lists.mkgmap.org.ukhttp://www.mkgmap.org.uk/mailman/listinfo/mkgmap-svn___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Branch is_in ready for a first test

[jan meisters]

Hi all,

thanks for the ongoing development.

I like the abstraction that Gerd has given, be it with digits or letters; and 
its implementation of all Tickers 6 cases.
With his explanation I could easily reproduce my simple but satisfying cemetery 
results as by 4418.

On Tickers argumentation my idea is limited, as I´m not able to understand all 
code internals he might has in mind.
Despite this - and if I got him correctly that it´s this logic we have now - it 
sounds adequate as well for what I can overlook.

Regarding the splitting proposed by Arndt I think it´s not always useful.
To handle improper drawings in OSM I´d prefer such a behaviour to be definable 
then.
Don´t know if I could need it.

Jan

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

Re: [mkgmap-dev] mapnik typ file and barrier=wall

[jan meisters]

yes, 0x17 never showed up in Basecamp for me either. Haven´t tested it on 
device then.

Jan

> Am 02.02.2020 um 09:51 schrieb Gerd Petermann 
> :
> 
> Hi TYP experts,
> 
> it seems that line type 0x17 (barrier=wall) is not visible in Basecamp?
> 
> Gerd
> 
> 
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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

Re: [mkgmap-dev] Test cases for possible is-in-hook

[jan meisters]

Hi all,

I would define the 6 cases in Tickers given (with the explained handling of 
apexes) as followed:

a) all-in   >   4/ 5/
b) all-in-or-on >   3/ 4/ 5/
c) all-on   >   3/
d) any-in   >   4/ 5/ 6/
Outside >   1/ 2/

These options are impressively complex, I can´t imagine any further yet.

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

Re: [mkgmap-dev] New branch is-in for experiments on style function is_in

[jan meisters]

Hi Gerd,

is the function still invoked with —is-in-hook=landuse…,  as before?
Or is it now just to be defined in the Style?
And which are the three parameters you mentioned?

Jan

> Am 30.12.2019 um 11:47 schrieb Gerd Petermann 
> :
> 
> Hi all,
> 
> with the help of Ticker I see a way to implement an is_in style function 
> I've created branch is-in to experiment with this. Sorry for the different 
> spelling is-in in the branch name!
> 
> Unfortunately I got no response regarding the contents of the file 
> is-in-hook-samples-v2.osm  posted here:
> http://gis.19327.n8.nabble.com/Test-cases-for-possible-is-in-hook-tp5954103.html
> So, Ticker and I have to guess what the function should do when a way or 
> polygon crosses or touches the boundary of
> a polygon with the given attribute.
> 
> The code in r4400 implements a function is_in with three parameters which 
> returns either true or false.
> It allows a rule like this in the lines file:
> highway=* & bicycle!=* & (is_in(landuse,cemetery,all) = true | 
> is_in(amenity,grave_yard,all) = true) {add bicycle=dismount}
> 
> or this one in the polygons file:
> # render building only when completely outside of a residential area
> building=* & building!=no & is_in(landuse,residential,any)=false [0x13 
> resolution 24]
> 
> A BIG question mark is the handling of rules which change the tags of 
> polygons. 
> Assume you have a rule like this in polygons:
> landuse=residential | landuse=commercial {set mylanduse=xyz}
> and somewhere else
> building=* & building!=no & is_in(mylanduse,xyz,any)=false [0x13 resolution 
> 24]
> 
> It might not be obvious but this could produce more or less unpredictable 
> results as it depends on the 
> order in which elements are processed. 
> 
> So, Ticker suggested to say "results of the is_in function are undefined when 
> tags of polygons are changed".
> I hope we can change this to something like "changing tags of polygons in the 
> style rules has no effect on the results of the is_in function"
> by creating copies of elements before the style rules are applied.
> 
> Gerd
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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

Re: [mkgmap-dev] Commit r4398: revert changes from r4397 (--is-in-landuse option)

[jan meisters]

Hi Gerd,great job!Concerning my english: I understand straddle as effectively outside, correct?Until now I only focussed on lines. In the samples every scenario of them looks good to me, if straddle=out. If not, hmm.For w26 i expect in.Attached is another example, stripped from OSM for residential also.By 4397 the whole track is rendered as in.With patched 4398 the line is split at the top west point of the residential llanduse and from there processed as in to the east.But I would expect it as completely out.(The original is here: https://www.openstreetmap.org/way/17937104, and I ask for allotments as in)Jan

is-in-bsp-zuendorf.osm
Description: application/osm
Am 20.12.2019 um 19:56 schrieb Arndt Röhrig :

  
   
 
 
  
   Hi Gerd,
  
  
   
  
  
   with r4397 i used this:
  
  
   
  
  
   mkgmap:lu:cemetery=* &! ((route_mtb=*|route_icn=*|route_ncn=*|route_lcn=*|route_rcn=*) | bicycle~'yes|official|designated|dismount|ok') {set rad=nein}
  
  
   
  
  
   and this
  
  
   
  
  
   highway~'unclassified|minor' &!(mkgmap:lu:residential=*) &!(tunnel=*) { name'${LangBez}'} [0x10112 resolution 24 continue]
   highway~'unclassified|minor' &!(mkgmap:lu:residential=*) &!(tunnel=*) { name'${LangBez}'} [0x10113 resolution 23-22 continue]
   highway~'unclassified|minor' &!(mkgmap:lu:residential=*) &!(tunnel=*) { name'${LangBez}'} [0x10114 resolution 21-21 continue]
   highway~'unclassified|minor' &!(mkgmap:lu:residential=*) &!(tunnel=*) { name'${LangBez}'} [0x10115 resolution 20-20 continue]
   highway~'unclassified|minor' &(mkgmap:lu:residential=*) &!(tunnel=*) { name'${LangBez}'} [0x10112 resolution 24 continue]
   highway~'unclassified|minor' &(mkgmap:lu:residential=*) &!(tunnel=*) { name'${LangBez}'} [0x10113 resolution 23-23 continue]
   highway~'unclassified|minor' &(mkgmap:lu:residential=*) &!(tunnel=*) { name'${LangBez}'} [0x10114 resolution 22-21 continue]
   highway~'unclassified|minor' &(mkgmap:lu:residential=*) &!(tunnel=*) { name'${LangBez}'} [0x10115 resolution 20-20 continue]
  
  
   
  
  
   I think it´s nice, to expand the function mkgmap:lu:cemetery, so that some other polys (playground, military, deponie etc) work with this.
  
  
   
  
  
   i don´t understand all mails, because my english is .(:
  
  
   
  
  
   Thank you for all the work you do! 
  
  
   
  
  
   best regards
  
  
   
  
  
   Arndt
  
  
   
Gerd Petermann <
gpetermann_muenc...@hotmail.com> hat am 20. Dezember 2019 um 18:32 geschrieben:
   
   

   
   

   
   
Hi all,
   
   

   
   
attached is an OSM file with various test cases. Assume we want to get the result for landuse=residential.
   
   
Please load it in JOSM and search for expected=in or expected=out or expected=straddle and finally expected="?"
   
   
and let me know as soon as possible if you don't agree with anything. (each case has a different name for the object to be tested.
   
   
The cases with "?" are special, I think b9 and b10 are not important, but the others are very usual in real OSM data.
   
   
The existing ResidentialHook would add mkgmap:residential to b13, b14 and w26.
   
   

   
   
@Ticker:
   
   
The residential areas around b13 and b14 show the special case with multipolygons. The hook probably "sees" something like the b13 example when looking at b14 because the multipolygons are cut into pieces without holes before the hook is executed.
   
   

   
   
@all: Would be very good to get some feedback on this, even if you think that you don't need the hook for your style.
   
   

   
   
Gerd
   
   

   
   

   
   
Von: mkgmap-dev <
mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <
rwb-mkg...@jagit.co.uk>
   
   
Gesendet: Freitag, 20. Dezember 2019 13:49
   
   
An: mkgmap development
   
   
Betreff: Re: [mkgmap-dev] Commit r4398: revert changes from r4397 (--is-in-landuse option)
   
   

   
   
Hi
   
   

   
   
Given the complexity and cpu cost of calculating this, the various
   
   
questions, hence answers possible and it has to be done for all
   
   
elements if the --is-in option is given what about making it a function
   
   
instead.
   
   

   
   
This means that it only needs to be computed for elements where the
   
   
answer matters and, as a parameter, the question about what the
   
   
required is-in means can be asked.
   
   

   
   
eg, in points:
   
   

   
   
if building=church and is-in('landuse', 'cemetery')
   
   
{add name='Chapel of Rest'}
   
   

   
   
in lines:
   
   

   
   
if highway=* and is-in('landuse', 'cemetary', 'fully') {add bicycle=no}
   
   

   
   
etc.
   
   
Above are just approximations of how the parameters might work.
   
   
The various levels of is-in that might 

Re: [mkgmap-dev] Commit r4397: implement and document new option --is-in-landuse=value[, value...]

[jan meisters]

Hi all,

while testing up to r4397 with is-in I had a lot of erratic results, most of 
them due to overlapping or area-crossings.
So - if reasonable - I opt for Tickers approach.

Jan

> Am 17.12.2019 um 19:39 schrieb Gerd Petermann 
> :
> 
> Hi Ticker,
> 
> I can draw two triangles A and B in such a way that they are overlapping but 
> no point of A is in B and no point of B is in A.
> 
> Of course I can also draw an unclosed straight way which lies almost 
> completely within an area but endpoints are outside.
> So, as long as we don't perform much more complex tests we just get a good 
> guess.
> 
> So, for a precise result I would not want to do the calculation for all 
> elements just in case the style might ask for it.
> 
> Gerd
> 
> 
> Von: mkgmap-dev  im Auftrag von 
> Ticker Berkin 
> Gesendet: Dienstag, 17. Dezember 2019 18:05
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Commit r4397: implement and document new option 
> --is-in-landuse=value[, value...]
> 
> Hi Gerd
> 
> I was thinking it would be slow to do the full test and I've seen your
> summary of what you've implemented and have no problem with it.
> 
> The meaning with either being multiPolygons would be almost impossible
> to define, but otherwise I'd define it as such:
> 
> Point: if within or on edge then IN otherwise OUT.
> 
> Way/polygons: if all points are outside or on edge, then OUT, if some
> are inside and some outside then STRADDLE, otherwise, ie at least 1
> point is inside, IN
> 
> Ticker
> 
> On Tue, 2019-12-17 at 13:32 +, Gerd Petermann wrote:
>> Hi Ticker,
>> 
>> I agree it would be good to know.
>> Problem: it would require a completely different implementation and
>> probably a lot more CPU power to compute that information.
>> 
>> The current test is very lazy, it works like the one for the
>> mkgmap:admin_level tags. It computes a single point that represents
>> the OSM element
>> and checks if that point is within or on the boundary of any
>> landuse=x polygon. I think that was OK for the original problem
>> (building inside landuse=residential),
>> but it was already problematic with the idea to set a maxspeed value
>> for a major highway "inside" a residential area.
>> 
>> So, what results do we get?
>> - A point is either outside, inside or on the boundary of a polygon.
>> - A line or polygon can be outside, inside, on the boundary or partly
>> overlapping a single polygon. What would be the result for a way that
>> builds a part of the boundary of two natural=wood multipolygons? What
>> would be the result when the way crosses such a boundary, but is
>> always inside one of the natural=wood polygons? Also, a way can be
>> inside one polygon and partly inside another, as OSM allows
>> overlapping polygons.
>> Think of a landuse=forest multipolygon with an inner way
>> natural=water . Is the inner way inside, outside or on the boundary?
>> Remenber, the hook doesn't "see" the multipolygon, it processes the
>> results of the MultipolygonCutter.
>> 
>> For JOSM I've implemented some area operators like a inside b or vice
>> versa, also a not inside b, but they only work on nodes and polygons,
>> and they are rather slow.
>> See https://josm.openstreetmap.de/ticket/10391
>> I assume you have something similar in mind?
>> 
>> Gerd
>> 
>> 
>> 
>> 
>> 
>> Von: Pinns UK 
>> Gesendet: Dienstag, 17. Dezember 2019 13:08
>> An: Gerd Petermann; mkgmap-dev@lists.mkgmap.org.uk
>> Betreff: Re: AW: [mkgmap-dev] Commit r4397: implement and document
>> new option --is-in-landuse=value[, value...]
>> 
>> Hi Gerd
>> 
>> That would be very useful
>> 
>> r
>> 
>> Nick
>> 
>> On 17/12/2019 11:15, Gerd Petermann wrote:
>>> Hi Nick,
>>> 
>>> OK, I already expected this when I asked if landuse is enough...
>>> I'll add code to support all polygons and see how to document it. I
>>> guess it should be no problem when I revert the changes in r4397.
>>> 
>>> Gerd
>>> 
>>> 
>>> Von: mkgmap-dev  im Auftrag
>>> von Pinns UK 
>>> Gesendet: Dienstag, 17. Dezember 2019 11:53
>>> An: mkgmap-dev@lists.mkgmap.org.uk
>>> Betreff: Re: [mkgmap-dev] Commit r4397: implement and document new
>>> option --is-in-landuse=value[, value...]
>>> 
>>> Hi Gerd,
>>> 
>>> Oops, I forgot to look at the documentation!
>>> 
>>> Personally , I think it is such a useful option which will open up
>>> a host of new possibilities when/if you are able to extend this to
>>> include all polygons.
>>> 
>>> Again, thanks for all your hard work!
>>> 
>>> Nick
>>> 
>>> On 17/12/2019 09:42, Pinns UK wrote:
>>> 
>>> Hi Gerd
>>> 
>>> I've been able to change footpaths on (some?)  amenity graveyards
>>> to paths by just setting the lu:cemetery to yes
>>> 
>>> I first tried :
>>> 
>>> amenity=grave_yard {set landuse=cemetry;echotags"change2landuse"}
>>> 
>>>   mkgmap:lu:cemetery=*  & highway=footway  {set highway=path}
>>> 
>>> 
>>> however this did 

Re: [mkgmap-dev] DEM contrast option?

[jan meisters]

Hi Gerd,

all screenshots show the same part of the same map:
- the first pair with the dedicated Typ-file
- the second pair with a matching transparent Typ-file (all polygons, 
lines and points are transparent/invisible with this Typ)

Inside a pair the screenshots differ in the detail-settings of BaseCamp - see 
the dark overlay at the bottom.
• 1: dedicated Typ - low detail BaseCamp
• 2: dedicated Typ - high detail BaseCamp
• 3: transparent Typ - low detail BaseCamp
• 4: transparent Typ - high detail BaseCamp

I wanted to point out, that the contrast of the DEM lowers when viewing higher 
details in BaseCamp.
It´s clearly visible on the transparent view how less bright/dark the shading 
gets in higher details.

I would prefer to see the HIGHER contrasting DEM over all detail-settings in 
BaseCamp.  

Question is how to adjust it. As the different strength in shading is rendered 
- shouldn´t there be a reason for it?
Any dem-dists, interpolation and overview-dem-dist combinations behaved as 
expected regarding DEM details - but not the contrast.

Any eventual mistake in my style I hope to disregard by the transparent view to 
the map.

Jan

> Am 09.07.2018 um 17:29 schrieb Gerd Petermann 
> :
> 
> Hi Jan,
> 
> to be honest, I don't even understand how you produce the two different 
> screen shots. If you prefer one of the two,
> why/when do you use the other?
> 
> Gerd
> 
> ____
> Von: mkgmap-dev  im Auftrag von jan 
> meisters 
> Gesendet: Montag, 9. Juli 2018 16:25
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] DEM contrast option?
> 
> Which resolution exactly do you mean?
> I already described that I tried different values for dem-dists (including 
> one single resolution).
> This, of course, has a huge effect on DETAILS, but not on CONTRAST.
> 
> Anybody has an idea how to adjust contrast?
> 
> Am 05.07.2018 um 20:20 schrieb Felix Hartmann 
> mailto:extremecar...@gmail.com>>:
> 
> You should only use one single resolution
> 
> On Thu, 5 Jul 2018, 19:31 jan meisters, 
> mailto:jan_...@gmx.net>> wrote:
> Tried a lot of dem-dist variations: fixed resolution as you hinted, 
> decreasing and even inverted steps.
> Unfortunately nothing changed the shown behavior.
> 
> What I´d like to see is the same CONTRAST in the shading over all resolutions.
> In higher resolutions the darks of the DEM are clearly brighter, whatever 
> dem-dists used.
> With the blank screenshots I wanted to show that there is no additional 
> (higher resolution) polygon in my style eventually hiding the DEM.
> 
> Had some success (at least on DEM contrasts) mixing levels and 
> overview-levels, but that obviously breaks the rest of the map.
> 
> Jan
> 
> 
> Am 04.07.2018 um 21:14 schrieb Felix Hartmann 
> mailto:extremecar...@gmail.com>>:
> 
> if you have several dem resolution levels in mkgmap - then it will lose in 
> detail (in order to zoom in/out faster). You could just create the map is a 
> single dem resolution - then detail level is always the same.
> 
> On 4 July 2018 at 18:52, jan meisters 
> mailto:jan_...@gmx.net>> wrote:
> I just made my first map with the new DEM-option and I´m impressed. Pretty 
> easy.
> But I wonder why DEM shading looses contrast in higher resolutions in 
> BaseCamp:
> 
> <1DEM_low.jpg><2DEM_higk.jpg>
> 
> My Style has background poly 4a and 4b (both transparent), however they are 
> not mentioned in polygons. I wouldn´t know how to tag them anyway.
> And even with a completely blanked typ-file the difference is visible:
> 
> <3DEM_low-e.jpg><4DEM_high-e.jpg>
> 
> HGT´s are 3“ data from 
> viewfinderpanaramas.org<http://viewfinderpanaramas.org/>
> 
> To keep the contrasted DEM up to higher resolutions/zooms I played with all 
> DEM-options from help, and also with transparencies, but that had no effect - 
> the softer shading remains.
> 
> I see the switch in Basecamp somewhere between assumed resolutions 20 and 22.
> How is this switch defined? Is there a value to adjust this?
> 
> Jan
> 
> 
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> 
> 
> 
> --
> Felix Hartman - Openmtbmap.org<http://openmtbmap.org/> & 
> VeloMap.org<http://velomap.org/>
> Schusterbergweg 32/8
> 6020 Innsbruck
> Austria - Österreich
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>
> htt

Re: [mkgmap-dev] DEM contrast option?

[jan meisters]

Which resolution exactly do you mean?
I already described that I tried different values for dem-dists (including one 
single resolution).
This, of course, has a huge effect on DETAILS, but not on CONTRAST.

Anybody has an idea how to adjust contrast?

> Am 05.07.2018 um 20:20 schrieb Felix Hartmann :
> 
> You should only use one single resolution
> 
> On Thu, 5 Jul 2018, 19:31 jan meisters,  <mailto:jan_...@gmx.net>> wrote:
> Tried a lot of dem-dist variations: fixed resolution as you hinted, 
> decreasing and even inverted steps.
> Unfortunately nothing changed the shown behavior.
> 
> What I´d like to see is the same CONTRAST in the shading over all resolutions.
> In higher resolutions the darks of the DEM are clearly brighter, whatever 
> dem-dists used.
> With the blank screenshots I wanted to show that there is no additional 
> (higher resolution) polygon in my style eventually hiding the DEM.
> 
> Had some success (at least on DEM contrasts) mixing levels and 
> overview-levels, but that obviously breaks the rest of the map.
> 
> Jan
> 
> 
>> Am 04.07.2018 um 21:14 schrieb Felix Hartmann > <mailto:extremecar...@gmail.com>>:
>> 
>> if you have several dem resolution levels in mkgmap - then it will lose in 
>> detail (in order to zoom in/out faster). You could just create the map is a 
>> single dem resolution - then detail level is always the same.
>> 
>> On 4 July 2018 at 18:52, jan meisters > <mailto:jan_...@gmx.net>> wrote:
>> I just made my first map with the new DEM-option and I´m impressed. Pretty 
>> easy.
>> But I wonder why DEM shading looses contrast in higher resolutions in 
>> BaseCamp:
>> 
>> <1DEM_low.jpg><2DEM_higk.jpg>
>> 
>> My Style has background poly 4a and 4b (both transparent), however they are 
>> not mentioned in polygons. I wouldn´t know how to tag them anyway.
>> And even with a completely blanked typ-file the difference is visible:
>> 
>> <3DEM_low-e.jpg><4DEM_high-e.jpg>
>> 
>> HGT´s are 3“ data from viewfinderpanaramas.org 
>> <http://viewfinderpanaramas.org/>
>> 
>> To keep the contrasted DEM up to higher resolutions/zooms I played with all 
>> DEM-options from help, and also with transparencies, but that had no effect 
>> - the softer shading remains.
>> 
>> I see the switch in Basecamp somewhere between assumed resolutions 20 and 22.
>> How is this switch defined? Is there a value to adjust this?
>> 
>> Jan
>> 
>> 
>> ___
>> mkgmap-dev mailing list
>> mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk>
>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev 
>> <http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev>
>> 
>> 
>> 
>> -- 
>> Felix Hartman - Openmtbmap.org <http://openmtbmap.org/> & VeloMap.org 
>> <http://velomap.org/>
>> Schusterbergweg 32/8
>> 6020 Innsbruck
>> Austria - Österreich
>> ___
>> mkgmap-dev mailing list
>> mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk>
>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev 
>> <http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev>
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk>
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev 
> <http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev>___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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

Re: [mkgmap-dev] DEM contrast option?

[jan meisters]

Tried a lot of dem-dist variations: fixed resolution as you hinted, decreasing 
and even inverted steps.
Unfortunately nothing changed the shown behavior.

What I´d like to see is the same CONTRAST in the shading over all resolutions.
In higher resolutions the darks of the DEM are clearly brighter, whatever 
dem-dists used.
With the blank screenshots I wanted to show that there is no additional (higher 
resolution) polygon in my style eventually hiding the DEM.

Had some success (at least on DEM contrasts) mixing levels and overview-levels, 
but that obviously breaks the rest of the map.

Jan


> Am 04.07.2018 um 21:14 schrieb Felix Hartmann :
> 
> if you have several dem resolution levels in mkgmap - then it will lose in 
> detail (in order to zoom in/out faster). You could just create the map is a 
> single dem resolution - then detail level is always the same.
> 
> On 4 July 2018 at 18:52, jan meisters  <mailto:jan_...@gmx.net>> wrote:
> I just made my first map with the new DEM-option and I´m impressed. Pretty 
> easy.
> But I wonder why DEM shading looses contrast in higher resolutions in 
> BaseCamp:
> 
> <1DEM_low.jpg><2DEM_higk.jpg>
> 
> My Style has background poly 4a and 4b (both transparent), however they are 
> not mentioned in polygons. I wouldn´t know how to tag them anyway.
> And even with a completely blanked typ-file the difference is visible:
> 
> <3DEM_low-e.jpg><4DEM_high-e.jpg>
> 
> HGT´s are 3“ data from viewfinderpanaramas.org 
> <http://viewfinderpanaramas.org/>
> 
> To keep the contrasted DEM up to higher resolutions/zooms I played with all 
> DEM-options from help, and also with transparencies, but that had no effect - 
> the softer shading remains.
> 
> I see the switch in Basecamp somewhere between assumed resolutions 20 and 22.
> How is this switch defined? Is there a value to adjust this?
> 
> Jan
> 
> 
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk>
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev 
> <http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev>
> 
> 
> 
> -- 
> Felix Hartman - Openmtbmap.org & VeloMap.org
> Schusterbergweg 32/8
> 6020 Innsbruck
> Austria - Österreich
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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

[mkgmap-dev] mkgmap and MapInstall (OS X)

[jan meisters]

Every several month I render my own europe from geofabrik extract, with OSX 
10.11.6 and a style-sheet based on openfietsmap. Mkgmap output is then 
converted to .gmap with JaVaWa MapConverter and viewed in BaseCamp.

This time, with mkgmap_3972 and splitter_583, the resulting map seems to be ok 
in BaseCamp, but MapInstall rejects to send anything to the device - no tile of 
the map is selectable.

I reproduced this failure with a fresh europe-latest a second time, while a 
smaller extract (Nordrhein-Westfalen) works.
Downgrading to last used mkgmap_3820 solved the problem in MapInstall - the 
rendered europe-output is functional for the whole workflow.

Is this a bug or something new in mkgmap I have to adjust in my style?

Thanks for reading!
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev