[mkgmap-dev] problem

[Steve Sgalowski]

I am using pinns.co.uk map uploader program with  mkgmap and splitter
 packs , but there as been no success at all
ok still have same prob , where if your in a directory , it stops due to
spaces .
 but root directory is ok .

but when i start to split it fails , has error

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

[mkgmap-dev] Problem writing line ...

[Gerd Petermann]

Hi Ticker,

please see https://files.mkgmap.org.uk/detail/513
This is what I get:
D:\mkgmap>java -ea -jar dist\mkgmap.jar  
e:\osm_out_work\norway\20210511_095323\63240001.o5m
Mkgmap version 4763
Time started: Thu Jun 10 10:50:35 CEST 2021
SCHWERWIEGEND (Polyline): e:\osm_out_work\norway\20210511_095323\63240001.o5m: 
Problem writing line (class uk.me.parabola.imgfmt.app.trergn.Polygon) of type 
0x16 containing 30 points and starting at 
http://www.openstreetmap.org/?mlat=62.987366&mlon=-1.137106&zoom=17
SCHWERWIEGEND (Polyline): e:\osm_out_work\norway\20210511_095323\63240001.o5m:  
 Subdivision shift is 0 and its centre is at 
http://www.openstreetmap.org/?mlat=62.263577&mlon=-1.478584&zoom=17
SCHWERWIEGEND (Polyline): e:\osm_out_work\norway\20210511_095323\63240001.o5m:  
 deltaLat = 33731
Number of MapFailedExceptions: 0
Number of ExitExceptions: 0
Time finished: Thu Jun 10 10:50:48 CEST 2021
Total time taken: 13 seconds

I've not looked at all the details, but the polygon overlaps the inital area 
extremely.  The attached patch fixes the problem but I have not tested any side 
effects.

Gerd



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

[mkgmap-dev] problem with boundarys

[Arndt Röhrig]

 
 
  
   Hi @all,
  
  
   
  
  
   my maps don´t show boundary=administrative anymore. i don´t know why. 
  
  
   
  
  
   
  
  
   What is wrong here? The following rules don´t change since 2018:
  
  
   
  
  
   relation:
  
  
   
  
  
   
boundary=administrative {apply {set grenze=ja}}
(type=boundary | type=multipolygon) & boundary=administrative & (admin_level~'[1-2]')
{ apply
{
set grenze1='$(grenze1) - ${name}' | '${name}';
}
}
   
   
(type=boundary | type=multipolygon) & boundary=administrative & (admin_level~'[3-4]')
{ apply
{
set grenze2='$(grenze2) - ${name}' | '${name}';
}
}
   
   
(type=boundary | type=multipolygon) & boundary=administrative & (admin_level~'[5-9]')
{ apply
{
set grenze3='$(grenze3) - ${name}' | '${name}';
}
}
   
   
(type=boundary | type=multipolygon) & boundary=administrative & (admin_level=10)
{ apply
{
set grenze3='$(grenze3) - ${name}' | '${name}';
}
}
   
   
(type=boundary | type=multipolygon) & boundary=administrative & (admin_level=11)
{ apply
{
set grenze3='$(grenze3) - ${name}' | '${name}';
}
}
   
  
  
   lines:
  
  
   # Grenzen
   grenze1=* { name '${grenze1}' | '${name}'} [0x1e resolution 18 continue]
   grenze2=* { name '${grenze2}' | '${name}'} [0x1d resolution 18 continue]
   grenze3=* { name '${grenze3}' | '${name}'} [0x1c resolution 21 continue]
   grenze=ja &! (grenze1=*|grenze2=*|grenze3=*) [0x1c resolution 21 continue]
  
  
   
  
  
   Greetz 
  
  
   Arndt
  
 

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

[mkgmap-dev] Problem in AngleFixer?

[Gerd Petermann]

Hi all,

in a private email Thorsten Kukuk contacted me about wrong turn instructions a 
sharp angles.
An example is the node https://www.osm.org/node/27550903

A route coming from South that follows the way https://www.osm.org/way/36138336 
at this junction should NOT produce a turn instruction.
A route that turns left SHOULD produce a turn instruction. 
With current mkgmap it's vice versa and thus not OK.

I thnk the current code in AngleFixer.java is too agressive as it tries to 
enlarge the angles so that a compact format can be used to write the
heading values of the arcs at the mentioned node. It does this by changing the 
heading values of both arcs with go to the north.

@Ticker: The code was introduced with your arcHeading_v2.patch, but maybe it 
existed before.
Can you explain why the constant AngleChecker.SHARP_DEGREES is set to 46° 
instead of maybe 22.5° ?

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

[mkgmap-dev] problem with style

[Henning Scholland]

Hi,
does someone has an explanation, why the second line isn't rendered in 
the map? Only results of line 1 and 3 are visiblewith overview2 
r2616(haven't tried other versions).


Henning

highway=trunk& area!=yes & access=no { set name='${name} (${ref})' | 
'${ref}' | '${name}'} [0x10003 level 6 continue]
highway=trunk & area!=yes & access!=no { set name='${name} (${ref})' | 
'${ref}' | '${name}'} [0x10003 level 6-1 continue]
highway=trunk & area!=yes & access!=no { set name='${name} (${ref})' | 
'${ref}' | '${name}'} [0x03 road_class=1 road_speed=1 level 0 continue]


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

[mkgmap-dev] problem with foot!=

[nwillink]

Hi

I discovered a 'unusual' foot tag , ie foot=permissive.

http://www.openstreetmap.org/way/29411164

when trying change it to foot=yes, I  my echotags always show me foot=no ,
ie

foot=permissive {set foot=yes}


It appears that foot!=yes is parsed as Boolean ,foot=no - perhaps I'm wrong.
 
Any way around this?

Nick



--
View this message in context: 
http://gis.19327.n5.nabble.com/problem-with-foot-tp5797620.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] problem in mkgmap

[Steve Sgalowski]

1
africa needs admin  level 5
bu unshure which state triggered this

then have a prob wher a bbox is not spli only found on compile


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

[mkgmap-dev] problem with mkgmap

[A Guertin]

Hello,

What can I do with this problem? Unable to split

See attachement

Andre
--







andre@G4 ~/geocaching_maps $ ls
carte   quebeclatest.osm   splitter.jar
mkgmap.jar  quebec-latest.osm.pbf  splitter-r427.zip
andre@G4 ~/geocaching_maps $ java -Xmx4096M -jar splitter.jar 
quebec-latest.osm.pbf 
Exception in thread "main" java.lang.NoClassDefFoundError: 
crosby/binary/file/BlockReaderAdapter
at java.lang.Class.getDeclaredMethods0(Native Method)
at java.lang.Class.privateGetDeclaredMethods(Class.java:2625)
at java.lang.Class.getMethod0(Class.java:2866)
at java.lang.Class.getMethod(Class.java:1676)
at sun.launcher.LauncherHelper.getMainMethod(LauncherHelper.java:494)
at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:486)
Caused by: java.lang.ClassNotFoundException: 
crosby.binary.file.BlockReaderAdapter
at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
... 6 more

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

[mkgmap-dev] Problem with r3706

[Arndt Röhrig]

Hello everybody,i use mkgmap r3706. It run 2 times. The first one makes the img-files. The second one makes the mdr/mdrx files. The first step works fine, without error-messages, but the second step produces an error message and crashes:"Exception in thread "main" java.lang.AssertionError: Invalid label offset found1315595    at uk.me.parabola.imgfmt.app.lbl.LBLFileReader.fetchLabel(LBLFileReader.java:87)    at uk.me.parabola.imgfmt.app.trergn.RGNFileReader.fetchPointsCommon(RGNFileReader.java:123)    at uk.me.parabola.imgfmt.app.trergn.RGNFileReader.pointsForSubdiv(RGNFileReader.java:84)    at uk.me.parabola.imgfmt.app.map.MapReader.pointsForLevel(MapReader.java:119)    at uk.me.parabola.mkgmap.combiners.MdrBuilder.addPoints(MdrBuilder.java:273)    at uk.me.parabola.mkgmap.combiners.MdrBuilder.onMapEnd(MdrBuilder.java:178)    at uk.me.parabola.mkgmap.main.Main.endOptions(Main.java:600)    at uk.me.parabola.mkgmap.CommandArgsReader.readArgs(CommandArgsReader.java:128)    at uk.me.parabola.mkgmap.main.Main.mainStart(Main.java:135)    at uk.me.parabola.mkgmap.main.Main.main(Main.java:106)"                        When i use mkgmap 3702 an error message at the first step appears, the second step works fine:"SCHWERWIEGEND (ShapeMergeFilter): ..\Splitter\8804.osm.pbf: ignoring shape with id 364926659 and type 0x13 at resolution 24, it has 4 points and has an empty area"The OSM-Data is "nordrhein-westfalen.osm.pbf". An other map "Kanaran" works fine, without error.Whats the reason for this and what can i do?Best regardsArndt
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] problem with splitter

[Henning Scholland]

Hi,
I discovered a problem with splitter.jar when using a areas.list with 
more then 255 tiles. If there are e.g. 256 tiles in one areas.list then 
splitter processes only half of the tiles e.g. 128. If there are 255 or 
less tiles inside, all tiles were processed.


Is this a bug or a feature?

It would be great, if there were no tilelimit because it is more 
effective to run splitter once with all tiles for all my maps and not 
run splitter two times. Without limit I would save 50% splittingtime.


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

[mkgmap-dev] Problem merging images

[Johannes Formann]

Hello,

after using the adress index feature, the image merging doesn't work
anymore.

java '-Xms256m' '-Xmx2560m' '-jar' 'mkgmap.jar' '--gmapsupp'
'gmapsupp_Basiskarte.img' '/home/osm/radkarte/gmapsupp_Hoehenlinien.img'
'gmapsupp_RadRouten.img' 'gmapsupp_Steigungen.img'
'gmapsupp_fixMeLayer.img'
 
Is this known?
Is there a workaround if it is known? I'd like to keep the
"Layer"-Feature so I'd be able to choose the maps on my Oregon 450 "on
demand".

greetings

Johannes

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

[mkgmap-dev] Problem with splitter

[Matteo Gottardi]

Hi, I noticed a problem splitting the geofabrik pbf extract of Italy
using the standard splitter-r200 options.

The area is at http://osm.org/go/0CmXpRz , and at
http://www.gomatteo.net/10.jpg you can see how it look in
QlandkarteGT.

The osm data seem ok, is a splitter problem?
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] Problem creating index

[Hakim DWAIK]

Hi all,

I am trying to compile a garmin map for an eTrex 30 device using the set of
utilities (osmconvert, osmfilter and of course mkgmap r2314)

I have some difficulties obtaining an index of all the cities for exemple
and after a week of research i decide to post a request on this mailing
list.

My osm file is cointaining arabian names for most of the poi names and i
want to display them on the gps device. I also want those names in the
index.

If you needed me to display each steps of my work, i can do it.

I have also compressed my osm and it is 12meg large now and can be send by
mail.

Thanks in advance for your answers.

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

[mkgmap-dev] Problem creating index

[Hakim DWAIK]

Hello again.
I detail my process just to be sure i didn't make a big mistake

I'm trying to make a map of syria, so i download the asia.pbf file and the
poly file


osmconvert --verbose syria\asia.osm.pbf -B=syria.poly --complex-ways
--complete-ways -o=syria.osm


I didn't split the file because apparently it is not necessary.


I have installed Java 64 bits on a W7 64 machine

When i try to compile the map with :

java -ea -Xmx2048g -jar mkgmap.jar -c myargs.args map.osm


Where myargs are:

code-page=1256
family-name="MyMap"
country-name="SYRIA"
country-abbr="SY"
remove-short-arcs
make-poi-index
index
route
gmapsupp


I got this error:


Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: -28
at
uk.me.parabola.imgfmt.app.srt.Sort$SrtCollator$PositionIterator.next(Sort.java:468)
at
uk.me.parabola.imgfmt.app.srt.Sort$SrtCollator.compareOneStrength(Sort.java:396)
at
uk.me.parabola.imgfmt.app.srt.Sort$SrtCollator.compare(Sort.java:363)
at
uk.me.parabola.imgfmt.app.mdr.PrefixIndex.createFromList(PrefixIndex.java:73)
at
uk.me.parabola.imgfmt.app.mdr.PrefixIndex.createFromList(PrefixIndex.java:99)
at uk.me.parabola.imgfmt.app.mdr.Mdr17.addPois(Mdr17.java:100)
at
uk.me.parabola.imgfmt.app.mdr.MDRFile.writeSections(MDRFile.java:301)
at uk.me.parabola.imgfmt.app.mdr.MDRFile.write(MDRFile.java:258)
at
uk.me.parabola.mkgmap.combiners.MdrBuilder.onFinishForDevice(MdrBuilder.java:382)
at
uk.me.parabola.mkgmap.combiners.GmapsuppBuilder.onFinish(GmapsuppBuilder.java:154)
at uk.me.parabola.mkgmap.main.Main.endOptions(Main.java:440)
at
uk.me.parabola.mkgmap.CommandArgsReader.readArgs(CommandArgsReader.java:126)
at uk.me.parabola.mkgmap.main.Main.main(Main.java:114)


I want to have on my eTrex30 the searchable list of cities for example.

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

[mkgmap-dev] Problem creating index

[Hakim DWAIK]

Hi,

I got this error with mkgmap r2311 and r2314...



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

[mkgmap-dev] Problem creating index

[Hakim DWAIK]

Hi Steve,

I dont have the compiling error anymore ! Thanks a lot.

But i also dont have my index in the img file.

I'm trying different solutions with the osm tools.

I don't want to bother this mailing list about compilation options if this
is only a dev forum.

Do you know other forums for osmtools (osmconvert, osmfilter and mkgmap) ?

Many thanks.

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

[mkgmap-dev] problem with style

[aighes]

Hi,
I've got a NPE while testing my style-file ( 
http://www.aighes.de/data/rrk_style.zip ).


Any guesses were the fault could be? Maybe a better errormessage could 
be generated by mkgmap in this case?


Henning

java -jar -Xmx6000M bin\mkgmap.jar --style-file=data\style_rrk --list-styles
Time started: Fri Sep 28 14:34:32 CEST 2012
The following styles are available:
Exception in thread "main" java.lang.NullPointerException
at 
uk.me.parabola.mkgmap.osmstyle.RuleFileReader.isIndexable(RuleFileReader.java:239)
at 
uk.me.parabola.mkgmap.osmstyle.RuleFileReader.isSolved(RuleFileReader.java:247)
at 
uk.me.parabola.mkgmap.osmstyle.RuleFileReader.isFinished(RuleFileReader.java:259)
at 
uk.me.parabola.mkgmap.osmstyle.RuleFileReader.rearrangeExpression(RuleFileReader.java:139)
at 
uk.me.parabola.mkgmap.osmstyle.RuleFileReader.rearrangeExpression(RuleFileReader.java:144)
at 
uk.me.parabola.mkgmap.osmstyle.RuleFileReader.saveRule(RuleFileReader.java:120)
at 
uk.me.parabola.mkgmap.osmstyle.RuleFileReader.load(RuleFileReader.java:96)
at 
uk.me.parabola.mkgmap.osmstyle.RuleFileReader.load(RuleFileReader.java:72)
at 
uk.me.parabola.mkgmap.osmstyle.StyleImpl.readRules(StyleImpl.java:304)
at 
uk.me.parabola.mkgmap.osmstyle.StyleImpl.(StyleImpl.java:146)

at uk.me.parabola.mkgmap.main.Main.listStyles(Main.java:289)
at uk.me.parabola.mkgmap.main.Main.processOption(Main.java:250)
at 
uk.me.parabola.mkgmap.CommandArgsReader$CommandOption.processArg(CommandArgsReader.java:297)
at 
uk.me.parabola.mkgmap.CommandArgsReader.readArgs(CommandArgsReader.java:123)

at uk.me.parabola.mkgmap.main.Main.main(Main.java:114)
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] Problem with styles

[sonke016]

Dear mkgmap users,

I have a problem when I'm trying to use a style. If I create a style, for 
example "fiets", put it in the folder "mkgmap\resources\styles\fiets", and I 
use the command
java -jar mkgmap.jar map.osm --tdbfile --style-file=styles\fiets
then mkgmap just uses the default style. I tried almost everything: using 
--style, using quotation marks, using --style-file=resources\styles\fiets etc.
I have no idea what I am doing wrong. Could someone please help me, for example 
by giving a working example command?

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

Re: [mkgmap-dev] Problem writing line ...

[Ticker Berkin]

Hi Gerd

Just tried this on my low-res build without your patch and don't get a
problem, but might be because of different options or pending
ShapeSplitter changes.

What options are you using? I'll disable my other changes and try again

Ticker


On Thu, 2021-06-10 at 09:00 +, Gerd Petermann wrote:
> Hi Ticker,
> 
> please see https://files.mkgmap.org.uk/detail/513
> This is what I get:
> D:\mkgmap>java -ea -jar dist\mkgmap.jar 
>  e:\osm_out_work\norway\20210511_095323\63240001.o5m
> Mkgmap version 4763
> Time started: Thu Jun 10 10:50:35 CEST 2021
> SCHWERWIEGEND (Polyline):
> e:\osm_out_work\norway\20210511_095323\63240001.o5m: Problem writing
> line (class uk.me.parabola.imgfmt.app.trergn.Polygon) of type 0x16
> containing 30 points and starting at 
> http://www.openstreetmap.org/?mlat=62.987366&mlon=-1.137106&zoom=17
> SCHWERWIEGEND (Polyline):
> e:\osm_out_work\norway\20210511_095323\63240001.o5m:   Subdivision
> shift is 0 and its centre is at 
> http://www.openstreetmap.org/?mlat=62.263577&mlon=-1.478584&zoom=17
> SCHWERWIEGEND (Polyline):
> e:\osm_out_work\norway\20210511_095323\63240001.o5m:   deltaLat =
> 33731
> Number of MapFailedExceptions: 0
> Number of ExitExceptions: 0
> Time finished: Thu Jun 10 10:50:48 CEST 2021
> Total time taken: 13 seconds
> 
> I've not looked at all the details, but the polygon overlaps the
> inital area extremely.  The attached patch fixes the problem but I
> have not tested any side effects.
> 
> Gerd
> 
> ___
> 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] Problem writing line ...

[Gerd Petermann]

Hi Ticker,

I got this with trunk and no options, just -ea is important.

Gerd


Von: mkgmap-dev  im Auftrag von Ticker 
Berkin 
Gesendet: Donnerstag, 10. Juni 2021 12:07
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Problem writing line ...

Hi Gerd

Just tried this on my low-res build without your patch and don't get a
problem, but might be because of different options or pending
ShapeSplitter changes.

What options are you using? I'll disable my other changes and try again

Ticker


On Thu, 2021-06-10 at 09:00 +, Gerd Petermann wrote:
> Hi Ticker,
>
> please see https://files.mkgmap.org.uk/detail/513
> This is what I get:
> D:\mkgmap>java -ea -jar dist\mkgmap.jar
>  e:\osm_out_work\norway\20210511_095323\63240001.o5m
> Mkgmap version 4763
> Time started: Thu Jun 10 10:50:35 CEST 2021
> SCHWERWIEGEND (Polyline):
> e:\osm_out_work\norway\20210511_095323\63240001.o5m: Problem writing
> line (class uk.me.parabola.imgfmt.app.trergn.Polygon) of type 0x16
> containing 30 points and starting at
> http://www.openstreetmap.org/?mlat=62.987366&mlon=-1.137106&zoom=17
> SCHWERWIEGEND (Polyline):
> e:\osm_out_work\norway\20210511_095323\63240001.o5m:   Subdivision
> shift is 0 and its centre is at
> http://www.openstreetmap.org/?mlat=62.263577&mlon=-1.478584&zoom=17
> SCHWERWIEGEND (Polyline):
> e:\osm_out_work\norway\20210511_095323\63240001.o5m:   deltaLat =
> 33731
> Number of MapFailedExceptions: 0
> Number of ExitExceptions: 0
> Time finished: Thu Jun 10 10:50:48 CEST 2021
> Total time taken: 13 seconds
>
> I've not looked at all the details, but the polygon overlaps the
> inital area extremely.  The attached patch fixes the problem but I
> have not tested any side effects.
>
> Gerd
>
> ___
> 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] Problem writing line ...

[Ticker Berkin]

Hi Gerd

OK - I get the problem now, it was --order-by that stopped it
happening. I think this oversize polygon should have been handled by
MapArea and the maxSize/maxWidth/maxHeight limits and I'm now trying to
work out why it isn't.

Ticker


On Thu, 2021-06-10 at 10:19 +, Gerd Petermann wrote:
> Hi Ticker,
> 
> I got this with trunk and no options, just -ea is important.
> 
> Gerd
> 
> 
> Von: mkgmap-dev  im Auftrag
> von Ticker Berkin 
> Gesendet: Donnerstag, 10. Juni 2021 12:07
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Problem writing line ...
> 
> Hi Gerd
> 
> Just tried this on my low-res build without your patch and don't get
> a
> problem, but might be because of different options or pending
> ShapeSplitter changes.
> 
> What options are you using? I'll disable my other changes and try
> again
> 
> Ticker
> 
> 
> On Thu, 2021-06-10 at 09:00 +, Gerd Petermann wrote:
> > Hi Ticker,
> > 
> > please see https://files.mkgmap.org.uk/detail/513
> > This is what I get:
> > D:\mkgmap>java -ea -jar dist\mkgmap.jar
> >  e:\osm_out_work\norway\20210511_095323\63240001.o5m
> > Mkgmap version 4763
> > Time started: Thu Jun 10 10:50:35 CEST 2021
> > SCHWERWIEGEND (Polyline):
> > e:\osm_out_work\norway\20210511_095323\63240001.o5m: Problem
> > writing
> > line (class uk.me.parabola.imgfmt.app.trergn.Polygon) of type 0x16
> > containing 30 points and starting at
> > http://www.openstreetmap.org/?mlat=62.987366&mlon=-1.137106&zoom=17
> > SCHWERWIEGEND (Polyline):
> > e:\osm_out_work\norway\20210511_095323\63240001.o5m:   Subdivision
> > shift is 0 and its centre is at
> > http://www.openstreetmap.org/?mlat=62.263577&mlon=-1.478584&zoom=17
> > SCHWERWIEGEND (Polyline):
> > e:\osm_out_work\norway\20210511_095323\63240001.o5m:   deltaLat =
> > 33731
> > Number of MapFailedExceptions: 0
> > Number of ExitExceptions: 0
> > Time finished: Thu Jun 10 10:50:48 CEST 2021
> > Total time taken: 13 seconds
> > 
> > I've not looked at all the details, but the polygon overlaps the
> > inital area extremely.  The attached patch fixes the problem but I
> > have not tested any side effects.
> > 
> > Gerd
> > 
> > ___
> > 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] Problem writing line ...

[Ticker Berkin]

Hi Gerd

I think you patch is the best solution. I was worried that it would
interfere with the subdiv/area sizing rules when --order-by, which does
allow very slightly oversized polgons, but these are never big enough
to cause the next level down to exceed MAX_DIVISION_SIZE.

Ticker

On Thu, 2021-06-10 at 11:56 +0100, Ticker Berkin wrote:
> Hi Gerd
> 
> OK - I get the problem now, it was --order-by that stopped it
> happening. I think this oversize polygon should have been handled by
> MapArea and the maxSize/maxWidth/maxHeight limits and I'm now trying
> to
> work out why it isn't.
> 
> Ticker
> 
> 
> On Thu, 2021-06-10 at 10:19 +, Gerd Petermann wrote:
> > Hi Ticker,
> > 
> > I got this with trunk and no options, just -ea is important.
> > 
> > Gerd
> > 
> > 
> > Von: mkgmap-dev  im Auftrag
> > von Ticker Berkin 
> > Gesendet: Donnerstag, 10. Juni 2021 12:07
> > An: Development list for mkgmap
> > Betreff: Re: [mkgmap-dev] Problem writing line ...
> > 
> > Hi Gerd
> > 
> > Just tried this on my low-res build without your patch and don't
> > get
> > a
> > problem, but might be because of different options or pending
> > ShapeSplitter changes.
> > 
> > What options are you using? I'll disable my other changes and try
> > again
> > 
> > Ticker
> > 
> > 
> > On Thu, 2021-06-10 at 09:00 +, Gerd Petermann wrote:
> > > Hi Ticker,
> > > 
> > > please see https://files.mkgmap.org.uk/detail/513
> > > This is what I get:
> > > D:\mkgmap>java -ea -jar dist\mkgmap.jar
> > >  e:\osm_out_work\norway\20210511_095323\63240001.o5m
> > > Mkgmap version 4763
> > > Time started: Thu Jun 10 10:50:35 CEST 2021
> > > SCHWERWIEGEND (Polyline):
> > > e:\osm_out_work\norway\20210511_095323\63240001.o5m: Problem
> > > writing
> > > line (class uk.me.parabola.imgfmt.app.trergn.Polygon) of type
> > > 0x16
> > > containing 30 points and starting at
> > > http://www.openstreetmap.org/?mlat=62.987366&mlon=-1.137106&zoom=
> > > 17
> > > SCHWERWIEGEND (Polyline):
> > > e:\osm_out_work\norway\20210511_095323\63240001.o5m:  
> > >  Subdivision
> > > shift is 0 and its centre is at
> > > http://www.openstreetmap.org/?mlat=62.263577&mlon=-1.478584&zoom=
> > > 17
> > > SCHWERWIEGEND (Polyline):
> > > e:\osm_out_work\norway\20210511_095323\63240001.o5m:   deltaLat =
> > > 33731
> > > Number of MapFailedExceptions: 0
> > > Number of ExitExceptions: 0
> > > Time finished: Thu Jun 10 10:50:48 CEST 2021
> > > Total time taken: 13 seconds
> > > 
> > > I've not looked at all the details, but the polygon overlaps the
> > > inital area extremely.  The attached patch fixes the problem but
> > > I
> > > have not tested any side effects.
> > > 
> > > Gerd
> > > 
> > > ___
> > > 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
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] problem with boundarys

[Gerd Petermann]

Hi Arndt,

might be a problem with the recent changes. r4767 still seems to work.

I'll try to find out why this changed.

Gerd


Von: mkgmap-dev  im Auftrag von Arndt 
Röhrig 
Gesendet: Samstag, 26. Juni 2021 16:22
An: Development list for mkgmap
Betreff: [mkgmap-dev] problem with boundarys

Hi @all,

my maps don´t show boundary=administrative anymore. i don´t know why.


What is wrong here? The following rules don´t change since 2018:

relation:

boundary=administrative {apply {set grenze=ja}}
(type=boundary | type=multipolygon) & boundary=administrative & 
(admin_level~'[1-2]')
{ apply
{
set grenze1='$(grenze1) - ${name}' | '${name}';
}
}
(type=boundary | type=multipolygon) & boundary=administrative & 
(admin_level~'[3-4]')
{ apply
{
set grenze2='$(grenze2) - ${name}' | '${name}';
}
}
(type=boundary | type=multipolygon) & boundary=administrative & 
(admin_level~'[5-9]')
{ apply
{
set grenze3='$(grenze3) - ${name}' | '${name}';
}
}
(type=boundary | type=multipolygon) & boundary=administrative & (admin_level=10)
{ apply
{
set grenze3='$(grenze3) - ${name}' | '${name}';
}
}
(type=boundary | type=multipolygon) & boundary=administrative & (admin_level=11)
{ apply
{
set grenze3='$(grenze3) - ${name}' | '${name}';
}
}
lines:
# Grenzen
grenze1=* { name '${grenze1}' | '${name}'} [0x1e resolution 18 continue]
grenze2=* { name '${grenze2}' | '${name}'} [0x1d resolution 18 continue]
grenze3=* { name '${grenze3}' | '${name}'} [0x1c resolution 21 continue]
grenze=ja &! (grenze1=*|grenze2=*|grenze3=*) [0x1c resolution 21 continue]

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

Re: [mkgmap-dev] problem with boundarys

[Arndt Röhrig]

 
 
  
   Hi Gerd,
  
  
   
  
  
   with r4767 i see the boundarys :)
  
  
   
  
  
   Greetz
  
  
   
  
  
   Arndt
  
  
   
Gerd Petermann <gpetermann_muenc...@hotmail.com> hat am 26.06.2021 16:47 geschrieben:
   
   

   
   

   
   
Hi Arndt,
   
   

   
   
might be a problem with the recent changes. r4767 still seems to work.
   
   

   
   
I'll try to find out why this changed.
   
   

   
   
Gerd
   
   

   
   

   
   
Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Arndt Röhrig <ar...@speichenkarte.de>
   
   
Gesendet: Samstag, 26. Juni 2021 16:22
   
   
An: Development list for mkgmap
   
   
    Betreff: [mkgmap-dev] problem with boundarys
   
   

   
   
Hi @all,
   
   

   
   
my maps don´t show boundary=administrative anymore. i don´t know why.
   
   

   
   

   
   
What is wrong here? The following rules don´t change since 2018:
   
   

   
   
relation:
   
   

   
   
boundary=administrative {apply {set grenze=ja}}
   
   
(type=boundary | type=multipolygon) & boundary=administrative & (admin_level~'[1-2]')
   
   
{ apply
   
   
{
   
   
set grenze1='$(grenze1) - ${name}' | '${name}';
   
   
}
   
   
}
   
   
(type=boundary | type=multipolygon) & boundary=administrative & (admin_level~'[3-4]')
   
   
{ apply
   
   
{
   
   
set grenze2='$(grenze2) - ${name}' | '${name}';
   
   
}
   
   
}
   
   
(type=boundary | type=multipolygon) & boundary=administrative & (admin_level~'[5-9]')
   
   
{ apply
   
   
{
   
   
set grenze3='$(grenze3) - ${name}' | '${name}';
   
   
}
   
   
}
   
   
(type=boundary | type=multipolygon) & boundary=administrative & (admin_level=10)
   
   
{ apply
   
   
{
   
   
set grenze3='$(grenze3) - ${name}' | '${name}';
   
   
}
   
   
}
   
   
(type=boundary | type=multipolygon) & boundary=administrative & (admin_level=11)
   
   
{ apply
   
   
{
   
   
set grenze3='$(grenze3) - ${name}' | '${name}';
   
   
}
   
   
}
   
   
lines:
   
   
# Grenzen
   
   
grenze1=* { name '${grenze1}' | '${name}'} [0x1e resolution 18 continue]
   
   
grenze2=* { name '${grenze2}' | '${name}'} [0x1d resolution 18 continue]
   
   
grenze3=* { name '${grenze3}' | '${name}'} [0x1c resolution 21 continue]
   
   
grenze=ja &! (grenze1=*|grenze2=*|grenze3=*) [0x1c resolution 21 continue]
   
   

   
   
Greetz
   
   
Arndt
   
   
___
   
   
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] Problem in splitter643

[Gerd Petermann]

Hi Valentin,

thanks for reporting, I can reproduce the problem and somehow expected this to 
happen.
Looking into this in the next days.

Gerd


Von: mkgmap-dev  im Auftrag von 
valenti...@inbox.ru 
Gesendet: Mittwoch, 24. November 2021 13:11
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: [mkgmap-dev] Problem in splitter643

Hi all.
In the last few days I getting a problem in splitter643 with Geofafrik whole 
Asia extract.
But splitter615 works without errors with the same osm source file.

java  -Xmx18g  -jar  splitter643.jar  --geonames-file=./cities1000.zip
--no-trim  --max-nodes=100  --output-dir=../splitterTiles-ASIA  
--output=pbf  ./asia-latest.o5m

Exception in thread "main" java.lang.StackOverflowError
at uk.me.parabola.splitter.solver.Tile.countInside(Tile.java:643)
at uk.me.parabola.splitter.solver.Tile.getMinParts(Tile.java:634)
at 
uk.me.parabola.splitter.solver.SplittableDensityArea$Solver.solve(SplittableDensityArea.java:1081)
at 
java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
at 
java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1384)
at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482)
at java.util.stream.ForEachOps$ForEachTask.compute(ForEachOps.java:290)
at java.util.concurrent.CountedCompleter.exec(CountedCompleter.java:731)
at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:289)
at java.util.concurrent.ForkJoinTask.doInvoke(ForkJoinTask.java:401)
at java.util.concurrent.ForkJoinTask.invoke(ForkJoinTask.java:734)
at 
java.util.stream.ForEachOps$ForEachOp.evaluateParallel(ForEachOps.java:159)
at 
java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateParallel(ForEachOps.java:173)
at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:233)
at 
java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:485)
at 
java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:650)
at 
uk.me.parabola.splitter.solver.SplittableDensityArea.solveRectangularAreaParallel(SplittableDensityArea.java:595)
at 
uk.me.parabola.splitter.solver.SplittableDensityArea.solveRectangularAreaParallel(SplittableDensityArea.java:627)
---the same string repeated more then one thousand times---
at 
uk.me.parabola.splitter.solver.SplittableDensityArea.solveRectangularAreaParallel(SplittableDensityArea.java:627)
*** Error code 1
Stop.

Link to the splitter643 log file:
https://maptourist.org/tmp/asia-split-log.zip
Link to the densities-out file:
https://maptourist.org/tmp/densities-out.zip

--
С уважением,
Валентин Кудрявцев  mailto:valenti...@inbox.ru

___
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] Problem in splitter643

[Gerd Petermann]

Hi Valentin,

this should be fixed with splitter-r645.

Gerd


Von: mkgmap-dev  im Auftrag von Gerd 
Petermann 
Gesendet: Mittwoch, 24. November 2021 14:24
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Problem in splitter643

Hi Valentin,

thanks for reporting, I can reproduce the problem and somehow expected this to 
happen.
Looking into this in the next days.

Gerd


Von: mkgmap-dev  im Auftrag von 
valenti...@inbox.ru 
Gesendet: Mittwoch, 24. November 2021 13:11
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: [mkgmap-dev] Problem in splitter643

Hi all.
In the last few days I getting a problem in splitter643 with Geofafrik whole 
Asia extract.
But splitter615 works without errors with the same osm source file.

java  -Xmx18g  -jar  splitter643.jar  --geonames-file=./cities1000.zip
--no-trim  --max-nodes=100  --output-dir=../splitterTiles-ASIA  
--output=pbf  ./asia-latest.o5m

Exception in thread "main" java.lang.StackOverflowError
at uk.me.parabola.splitter.solver.Tile.countInside(Tile.java:643)
at uk.me.parabola.splitter.solver.Tile.getMinParts(Tile.java:634)
at 
uk.me.parabola.splitter.solver.SplittableDensityArea$Solver.solve(SplittableDensityArea.java:1081)
at 
java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
at 
java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1384)
at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482)
at java.util.stream.ForEachOps$ForEachTask.compute(ForEachOps.java:290)
at java.util.concurrent.CountedCompleter.exec(CountedCompleter.java:731)
at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:289)
at java.util.concurrent.ForkJoinTask.doInvoke(ForkJoinTask.java:401)
at java.util.concurrent.ForkJoinTask.invoke(ForkJoinTask.java:734)
at 
java.util.stream.ForEachOps$ForEachOp.evaluateParallel(ForEachOps.java:159)
at 
java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateParallel(ForEachOps.java:173)
at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:233)
at 
java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:485)
at 
java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:650)
at 
uk.me.parabola.splitter.solver.SplittableDensityArea.solveRectangularAreaParallel(SplittableDensityArea.java:595)
at 
uk.me.parabola.splitter.solver.SplittableDensityArea.solveRectangularAreaParallel(SplittableDensityArea.java:627)
---the same string repeated more then one thousand times---
at 
uk.me.parabola.splitter.solver.SplittableDensityArea.solveRectangularAreaParallel(SplittableDensityArea.java:627)
*** Error code 1
Stop.

Link to the splitter643 log file:
https://maptourist.org/tmp/asia-split-log.zip
Link to the densities-out file:
https://maptourist.org/tmp/densities-out.zip

--
С уважением,
Валентин Кудрявцев  mailto:valenti...@inbox.ru

___
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] Problem in AngleFixer?

[Ticker Berkin]

Hi Gerd

I'll need to look carefully at this code again.

ISTR the 46 degrees was to stop arcs getting into the same compact segment when
they shouldn't. My changes stopped a lot of incorrect turn instructions but
maybe there is still scope for the algorithm to look for the same road entered
and exiting in a straight line and try to preserve this by adjust other roads
more.

Noticed that, in the example, these are bike routes and it looks like the algo
ignores these.

Ticker 

On Mon, 2024-08-05 at 06:37 +, Gerd Petermann wrote:
> Hi all,
> 
> in a private email Thorsten Kukuk contacted me about wrong turn instructions a
> sharp angles.
> An example is the node https://www.osm.org/node/27550903
> 
> A route coming from South that follows the way
> https://www.osm.org/way/36138336 at this junction should NOT produce a turn
> instruction.
> A route that turns left SHOULD produce a turn instruction. 
> With current mkgmap it's vice versa and thus not OK.
> 
> I thnk the current code in AngleFixer.java is too agressive as it tries to
> enlarge the angles so that a compact format can be used to write the
> heading values of the arcs at the mentioned node. It does this by changing the
> heading values of both arcs with go to the north.
> 
> @Ticker: The code was introduced with your arcHeading_v2.patch, but maybe it
> existed before.
> Can you explain why the constant AngleChecker.SHARP_DEGREES is set to 46°
> instead of maybe 22.5° ?
> 
> Gerd
> ___
> 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] Problem in AngleFixer?

[Gerd Petermann]

Hi Ticker,

thanks, I didn't test much, but with a value of 22.5 (or 23) the problem 
disappeared. It also disappears with
--x-ignore-sharp-angles. Downgrade is that the NOD size increases a bit, but I 
think that is better than wrong turn instructions.

Let me know if you cannot reproduce and I'll create a more complete description 
reg. the options in use.

ciao,
Gerd


Von: mkgmap-dev  im Auftrag von Ticker 
Berkin 
Gesendet: Montag, 5. August 2024 10:42
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Problem in AngleFixer?

Hi Gerd

I'll need to look carefully at this code again.

ISTR the 46 degrees was to stop arcs getting into the same compact segment when
they shouldn't. My changes stopped a lot of incorrect turn instructions but
maybe there is still scope for the algorithm to look for the same road entered
and exiting in a straight line and try to preserve this by adjust other roads
more.

Noticed that, in the example, these are bike routes and it looks like the algo
ignores these.

Ticker

On Mon, 2024-08-05 at 06:37 +, Gerd Petermann wrote:
> Hi all,
>
> in a private email Thorsten Kukuk contacted me about wrong turn instructions a
> sharp angles.
> An example is the node https://www.osm.org/node/27550903
>
> A route coming from South that follows the way
> https://www.osm.org/way/36138336 at this junction should NOT produce a turn
> instruction.
> A route that turns left SHOULD produce a turn instruction.
> With current mkgmap it's vice versa and thus not OK.
>
> I thnk the current code in AngleFixer.java is too agressive as it tries to
> enlarge the angles so that a compact format can be used to write the
> heading values of the arcs at the mentioned node. It does this by changing the
> heading values of both arcs with go to the north.
>
> @Ticker: The code was introduced with your arcHeading_v2.patch, but maybe it
> existed before.
> Can you explain why the constant AngleChecker.SHARP_DEGREES is set to 46°
> instead of maybe 22.5° ?
>
> Gerd
> ___
> 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] Problem in AngleFixer?

[Ticker Berkin]

Hi Gerd

I presume you are just changing SHARP_DEGREES, leaving COMPACT_DIR_DEGREES
alone.

In this example the arcs on either side of the sharp angle have the same
priority (class/speed) so there isn't an obvious one to adjust so the logic
adjusts both.

Also in this example, and very common, is a side turn off a basically straight
road and the proportions that each arc is adjusted isn't ideal in that the
straight road is bent slightly more than the side turn is adjusted.

This could be spotted as a special case: when there are 3 arcs and the available
angle on one side or the other (initial value of deltaPred or deltaNext) is
close to 180 degrees then just the other side should be adjusted. Maybe the 3
arcs doesn't really matter as long as there is sufficient space to adjust the
other side.

I'll do some experiments.

Ticker

On Mon, 2024-08-05 at 08:55 +, Gerd Petermann wrote:
> > > > Hi Ticker,
> > > > 
> > > > thanks, I didn't test much, but with a value of 22.5 (or 23) the problem
> > > > disappeared. It also disappears with
> > > > --x-ignore-sharp-angles. Downgrade is that the NOD size increases a bit,
> > > > but
> > > > I
> > > > think that is better than wrong turn instructions.
> > > > 
> > > > Let me know if you cannot reproduce and I'll create a more complete
> > > > description reg. the options in use.
> > > > 
> > > > ciao,
> > > > Gerd
> > > > 
> > > > ____________
> > > > Von: mkgmap-dev  im Auftrag von
> > > > Ticker
> > > > Berkin 
> > > > Gesendet: Montag, 5. August 2024 10:42
> > > > An: Development list for mkgmap
> > > > Betreff: Re: [mkgmap-dev] Problem in AngleFixer?
> > > > 
> > > > Hi Gerd
> > > > 
> > > > I'll need to look carefully at this code again.
> > > > 
> > > > ISTR the 46 degrees was to stop arcs getting into the same compact
> > > > segment
> > > > when
> > > > they shouldn't. My changes stopped a lot of incorrect turn instructions
> > > > but
> > > > maybe there is still scope for the algorithm to look for the same road
> > > > entered
> > > > and exiting in a straight line and try to preserve this by adjust other
> > > > roads
> > > > more.
> > > > 
> > > > Noticed that, in the example, these are bike routes and it looks like
> > > > the
> > > > algo
> > > > ignores these.
> > > > 
> > > > Ticker
> > > > 
> > > > On Mon, 2024-08-05 at 06:37 +, Gerd Petermann wrote:
> > > > > > > > Hi all,
> > > > > > > > 
> > > > > > > > in a private email Thorsten Kukuk contacted me about wrong turn
> > > > > > > > instructions
> > > > > > > > a
> > > > > > > > sharp angles.
> > > > > > > > An example is the node https://www.osm.org/node/27550903
> > > > > > > > 
> > > > > > > > A route coming from South that follows the way
> > > > > > > > https://www.osm.org/way/36138336 at this junction should NOT
> > > > > > > > produce a
> > > > > > > > turn
> > > > > > > > instruction.
> > > > > > > > A route that turns left SHOULD produce a turn instruction.
> > > > > > > > With current mkgmap it's vice versa and thus not OK.
> > > > > > > > 
> > > > > > > > I thnk the current code in AngleFixer.java is too agressive as
> > > > > > > > it tries
> > > > > > > > to
> > > > > > > > enlarge the angles so that a compact format can be used to write
> > > > > > > > the
> > > > > > > > heading values of the arcs at the mentioned node. It does this
> > > > > > > > by
> > > > > > > > changing
> > > > > > > > the
> > > > > > > > heading values of both arcs with go to the north.
> > > > > > > > 
> > > > > > > > @Ticker: The code was introduced with your arcHeading_v2.patch,
> > > > > > > > but
> > > > > > > > maybe it
> > > > > > > > existed before.
> > > > > > > > Can you explain why the constant AngleChecker.SHARP_DEGREES is
> > > > > > > > set to
> > > > > > > > 46°
> > > > > > > > instead of maybe 22.5° ?
> > > > > > > > 
> > > > > > > > Gerd
> > > > > > > > ___
> > > > > > > > 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] Problem in AngleFixer?

[Ticker Berkin]

Hi Gerd

Patch attached that, where possible, keeps ~straight roads unchanged and widens
the sharp angle on the other road.

This should fix the particular example and generally be better, although it is
difficult to test.

I try and note where I get incorrect turn instructions and later work out why
and, since the arcHeading_v2.patch in Oct 2020 I haven't found any that are
fixable; I couldn't find a solution where the major road continues at an angle
and the minor side road continues straight on.

Ticker

On Mon, 2024-08-05 at 19:14 +0100, Ticker Berkin wrote:
> Hi Gerd
> 
> I presume you are just changing SHARP_DEGREES, leaving COMPACT_DIR_DEGREES
> alone.
> 
> In this example the arcs on either side of the sharp angle have the same
> priority (class/speed) so there isn't an obvious one to adjust so the logic
> adjusts both.
> 
> Also in this example, and very common, is a side turn off a basically straight
> road and the proportions that each arc is adjusted isn't ideal in that the
> straight road is bent slightly more than the side turn is adjusted.
> 
> This could be spotted as a special case: when there are 3 arcs and the
> available
> angle on one side or the other (initial value of deltaPred or deltaNext) is
> close to 180 degrees then just the other side should be adjusted. Maybe the 3
> arcs doesn't really matter as long as there is sufficient space to adjust the
> other side.
> 
> I'll do some experiments.
> 
> Ticker
> 
> On Mon, 2024-08-05 at 08:55 +, Gerd Petermann wrote:
> > > > > Hi Ticker,
> > > > > 
> > > > > thanks, I didn't test much, but with a value of 22.5 (or 23) the
> > > > > problem
> > > > > disappeared. It also disappears with
> > > > > --x-ignore-sharp-angles. Downgrade is that the NOD size increases a
> > > > > bit,
> > > > > but
> > > > > I
> > > > > think that is better than wrong turn instructions.
> > > > > 
> > > > > Let me know if you cannot reproduce and I'll create a more complete
> > > > > description reg. the options in use.
> > > > > 
> > > > > ciao,
> > > > > Gerd
> > > > > 
> > > > > 
> > > > > Von: mkgmap-dev  im Auftrag
> > > > > von
> > > > > Ticker
> > > > > Berkin 
> > > > > Gesendet: Montag, 5. August 2024 10:42
> > > > > An: Development list for mkgmap
> > > > > Betreff: Re: [mkgmap-dev] Problem in AngleFixer?
> > > > > 
> > > > > Hi Gerd
> > > > > 
> > > > > I'll need to look carefully at this code again.
> > > > > 
> > > > > ISTR the 46 degrees was to stop arcs getting into the same compact
> > > > > segment
> > > > > when
> > > > > they shouldn't. My changes stopped a lot of incorrect turn
> > > > > instructions
> > > > > but
> > > > > maybe there is still scope for the algorithm to look for the same road
> > > > > entered
> > > > > and exiting in a straight line and try to preserve this by adjust
> > > > > other
> > > > > roads
> > > > > more.
> > > > > 
> > > > > Noticed that, in the example, these are bike routes and it looks like
> > > > > the
> > > > > algo
> > > > > ignores these.
> > > > > 
> > > > > Ticker
> > > > > 
> > > > > On Mon, 2024-08-05 at 06:37 +, Gerd Petermann wrote:
> > > > > > > > > Hi all,
> > > > > > > > > 
> > > > > > > > > in a private email Thorsten Kukuk contacted me about wrong
> > > > > > > > > turn
> > > > > > > > > instructions
> > > > > > > > > a
> > > > > > > > > sharp angles.
> > > > > > > > > An example is the node https://www.osm.org/node/27550903
> > > > > > > > > 
> > > > > > > > > A route coming from South that follows the way
> > > > > > > > > https://www.osm.org/way/36138336 at this junction should NOT
> > > > > > > > > produce a
> > > > > > > > > turn
> > > > > > > > > instruction.
> > >

Re: [mkgmap-dev] Problem in AngleFixer?

[Gerd Petermann]

Hi Ticker,

I'll have a look at the patch during the next days. Please ping me if I didn't 
react until August 20.

Gerd


Von: mkgmap-dev  im Auftrag von Ticker 
Berkin 
Gesendet: Dienstag, 6. August 2024 12:26
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Problem in AngleFixer?

Hi Gerd

Patch attached that, where possible, keeps ~straight roads unchanged and widens
the sharp angle on the other road.

This should fix the particular example and generally be better, although it is
difficult to test.

I try and note where I get incorrect turn instructions and later work out why
and, since the arcHeading_v2.patch in Oct 2020 I haven't found any that are
fixable; I couldn't find a solution where the major road continues at an angle
and the minor side road continues straight on.

Ticker

On Mon, 2024-08-05 at 19:14 +0100, Ticker Berkin wrote:
> Hi Gerd
>
> I presume you are just changing SHARP_DEGREES, leaving COMPACT_DIR_DEGREES
> alone.
>
> In this example the arcs on either side of the sharp angle have the same
> priority (class/speed) so there isn't an obvious one to adjust so the logic
> adjusts both.
>
> Also in this example, and very common, is a side turn off a basically straight
> road and the proportions that each arc is adjusted isn't ideal in that the
> straight road is bent slightly more than the side turn is adjusted.
>
> This could be spotted as a special case: when there are 3 arcs and the
> available
> angle on one side or the other (initial value of deltaPred or deltaNext) is
> close to 180 degrees then just the other side should be adjusted. Maybe the 3
> arcs doesn't really matter as long as there is sufficient space to adjust the
> other side.
>
> I'll do some experiments.
>
> Ticker
>
> On Mon, 2024-08-05 at 08:55 +, Gerd Petermann wrote:
> > > > > Hi Ticker,
> > > > >
> > > > > thanks, I didn't test much, but with a value of 22.5 (or 23) the
> > > > > problem
> > > > > disappeared. It also disappears with
> > > > > --x-ignore-sharp-angles. Downgrade is that the NOD size increases a
> > > > > bit,
> > > > > but
> > > > > I
> > > > > think that is better than wrong turn instructions.
> > > > >
> > > > > Let me know if you cannot reproduce and I'll create a more complete
> > > > > description reg. the options in use.
> > > > >
> > > > > ciao,
> > > > > Gerd
> > > > >
> > > > > 
> > > > > Von: mkgmap-dev  im Auftrag
> > > > > von
> > > > > Ticker
> > > > > Berkin 
> > > > > Gesendet: Montag, 5. August 2024 10:42
> > > > > An: Development list for mkgmap
> > > > > Betreff: Re: [mkgmap-dev] Problem in AngleFixer?
> > > > >
> > > > > Hi Gerd
> > > > >
> > > > > I'll need to look carefully at this code again.
> > > > >
> > > > > ISTR the 46 degrees was to stop arcs getting into the same compact
> > > > > segment
> > > > > when
> > > > > they shouldn't. My changes stopped a lot of incorrect turn
> > > > > instructions
> > > > > but
> > > > > maybe there is still scope for the algorithm to look for the same road
> > > > > entered
> > > > > and exiting in a straight line and try to preserve this by adjust
> > > > > other
> > > > > roads
> > > > > more.
> > > > >
> > > > > Noticed that, in the example, these are bike routes and it looks like
> > > > > the
> > > > > algo
> > > > > ignores these.
> > > > >
> > > > > Ticker
> > > > >
> > > > > On Mon, 2024-08-05 at 06:37 +, Gerd Petermann wrote:
> > > > > > > > > Hi all,
> > > > > > > > >
> > > > > > > > > in a private email Thorsten Kukuk contacted me about wrong
> > > > > > > > > turn
> > > > > > > > > instructions
> > > > > > > > > a
> > > > > > > > > sharp angles.
> > > > > > > > > An example is the node https://www.osm.org/node/27550903
> > > > > > > > >
> > > > > > > > > A route coming from South tha

Re: [mkgmap-dev] Problem in AngleFixer?

[Thorsten Kukuk]

Hi,

trying from another email account, with the other I always get an error 
when trying to send to the mailing list:
TLS Negotiation failed: FAILED_PRECONDITION: starttls error (71): 
123617668315712:error:112e:SSL 
routines:OPENSSL_internal:KEY_USAGE_BIT_INCORRECT:third_party/openssl/boringssl/src/ssl/ssl_cert.cc:431:



I tried the patch from Ticker, it fixes routing problems with sharp 
angles for me,

where previously Garmin devices would avoid the Junction.
But it does not fix the wrong turn instruction for me.

Regards,
Thorsten


Am 2024-08-07 14:07, schrieb Gerd Petermann:

Hi Ticker,

I'll have a look at the patch during the next days. Please ping me if I 
didn't react until August 20.


Gerd


Von: mkgmap-dev  im Auftrag von 
Ticker Berkin 

Gesendet: Dienstag, 6. August 2024 12:26
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Problem in AngleFixer?

Hi Gerd

Patch attached that, where possible, keeps ~straight roads unchanged 
and widens

the sharp angle on the other road.

This should fix the particular example and generally be better, 
although it is

difficult to test.

I try and note where I get incorrect turn instructions and later work 
out why
and, since the arcHeading_v2.patch in Oct 2020 I haven't found any that 
are
fixable; I couldn't find a solution where the major road continues at 
an angle

and the minor side road continues straight on.

Ticker

On Mon, 2024-08-05 at 19:14 +0100, Ticker Berkin wrote:

Hi Gerd

I presume you are just changing SHARP_DEGREES, leaving 
COMPACT_DIR_DEGREES

alone.

In this example the arcs on either side of the sharp angle have the 
same
priority (class/speed) so there isn't an obvious one to adjust so the 
logic

adjusts both.

Also in this example, and very common, is a side turn off a basically 
straight
road and the proportions that each arc is adjusted isn't ideal in that 
the

straight road is bent slightly more than the side turn is adjusted.

This could be spotted as a special case: when there are 3 arcs and the
available
angle on one side or the other (initial value of deltaPred or 
deltaNext) is
close to 180 degrees then just the other side should be adjusted. 
Maybe the 3
arcs doesn't really matter as long as there is sufficient space to 
adjust the

other side.

I'll do some experiments.

Ticker

On Mon, 2024-08-05 at 08:55 +, Gerd Petermann wrote:
> > > > Hi Ticker,
> > > >
> > > > thanks, I didn't test much, but with a value of 22.5 (or 23) the
> > > > problem
> > > > disappeared. It also disappears with
> > > > --x-ignore-sharp-angles. Downgrade is that the NOD size increases a
> > > > bit,
> > > > but
> > > > I
> > > > think that is better than wrong turn instructions.
> > > >
> > > > Let me know if you cannot reproduce and I'll create a more complete
> > > > description reg. the options in use.
> > > >
> > > > ciao,
> > > > Gerd
> > > >
> > > > 
> > > > Von: mkgmap-dev  im Auftrag
> > > > von
> > > > Ticker
> > > > Berkin 
> > > > Gesendet: Montag, 5. August 2024 10:42
> > > > An: Development list for mkgmap
> > > > Betreff: Re: [mkgmap-dev] Problem in AngleFixer?
> > > >
> > > > Hi Gerd
> > > >
> > > > I'll need to look carefully at this code again.
> > > >
> > > > ISTR the 46 degrees was to stop arcs getting into the same compact
> > > > segment
> > > > when
> > > > they shouldn't. My changes stopped a lot of incorrect turn
> > > > instructions
> > > > but
> > > > maybe there is still scope for the algorithm to look for the same road
> > > > entered
> > > > and exiting in a straight line and try to preserve this by adjust
> > > > other
> > > > roads
> > > > more.
> > > >
> > > > Noticed that, in the example, these are bike routes and it looks like
> > > > the
> > > > algo
> > > > ignores these.
> > > >
> > > > Ticker
> > > >
> > > > On Mon, 2024-08-05 at 06:37 +, Gerd Petermann wrote:
> > > > > > > > Hi all,
> > > > > > > >
> > > > > > > > in a private email Thorsten Kukuk contacted me about wrong
> > > > > > > > turn
> > > > > > > > instructions
> > > > > > > > a
> > > > > > > > sharp angles.
> &g

Re: [mkgmap-dev] Problem in AngleFixer?

[Ticker Berkin]

Hi Thorsten

Is the problem still with node https://www.osm.org/node/27550903 and ways
36138336 / 144732811

I've loaded this example and looked at the angles before and after adjustment
with my patch. From the south the way enters the node with heading 161.6 and
leaves with heading -16, giving an angle of 178.6 (almost straight). The other
way leaves with heading -32.4, giving a sharp angle of 15.4 degrees that the
logic will want to increase.

After the adjustments, the main way isn't changed and the other way is given a
new heading of -63 degrees.

In compactDir format the main way enters in seg 7 and leaves in seg 15 (direct
opposite) and the other way now leaves in seg 13 (a clear segment between the
other exit). This, I thought, would be enough to get the turn instruction on the
correct road.

I've forgotten how some of the forward and reverse arc stuff works and, if there
is still a problem, I need to re-understand it to make sure that the
manipulations that we do to the angles at a node make sense for all routes
through it

Ticker

PS: no ideal about your mail error


On Thu, 2024-08-08 at 11:45 +0200, Thorsten Kukuk wrote:
> 
> Hi,
> 
> trying from another email account, with the other I always get an error 
> when trying to send to the mailing list:
> TLS Negotiation failed: FAILED_PRECONDITION: starttls error (71): 
> 123617668315712:error:112e:SSL 
> routines:OPENSSL_internal:KEY_USAGE_BIT_INCORRECT:third_party/openssl/boringss
> l/src/ssl/ssl_cert.cc:431:
> 
> 
> I tried the patch from Ticker, it fixes routing problems with sharp 
> angles for me,
> where previously Garmin devices would avoid the Junction.
> But it does not fix the wrong turn instruction for me.
> 
> Regards,
> Thorsten

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

Re: [mkgmap-dev] Problem in AngleFixer?

[Thorsten Kukuk]

Hi,

Am 2024-08-08 14:22, schrieb Ticker Berkin:

Hi Thorsten

Is the problem still with node https://www.osm.org/node/27550903 and 
ways

36138336 / 144732811


Yes. That's one.
Else see below.

I've loaded this example and looked at the angles before and after 
adjustment
with my patch. From the south the way enters the node with heading 
161.6 and
leaves with heading -16, giving an angle of 178.6 (almost straight). 
The other
way leaves with heading -32.4, giving a sharp angle of 15.4 degrees 
that the

logic will want to increase.

After the adjustments, the main way isn't changed and the other way is 
given a

new heading of -63 degrees.

In compactDir format the main way enters in seg 7 and leaves in seg 15 
(direct
opposite) and the other way now leaves in seg 13 (a clear segment 
between the
other exit). This, I thought, would be enough to get the turn 
instruction on the

correct road.

I've forgotten how some of the forward and reverse arc stuff works and, 
if there

is still a problem, I need to re-understand it to make sure that the
manipulations that we do to the angles at a node make sense for all 
routes

through it


I don't know anything about the format.
Is there somehow a flag what is the main road, or is this navigation 
instruction purely based on the degree of the turn?

Because, I have more similar situations like here:
https://www.openstreetmap.org/#map=18/49.43041/10.99213

If you go from north to the south and have to turn right no instruction 
is coming, if you have to go straight forward, a "turn left" is coming.
Difference to the point above is, that the main road is make a turn 
right and the straight forward is a new, smaller way.


Regards,
Thorsten


Ticker

PS: no ideal about your mail error


On Thu, 2024-08-08 at 11:45 +0200, Thorsten Kukuk wrote:


Hi,

trying from another email account, with the other I always get an 
error

when trying to send to the mailing list:
TLS Negotiation failed: FAILED_PRECONDITION: starttls error (71):
123617668315712:error:112e:SSL
routines:OPENSSL_internal:KEY_USAGE_BIT_INCORRECT:third_party/openssl/boringss
l/src/ssl/ssl_cert.cc:431:


I tried the patch from Ticker, it fixes routing problems with sharp
angles for me,
where previously Garmin devices would avoid the Junction.
But it does not fix the wrong turn instruction for me.

Regards,
Thorsten


___
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] Problem in AngleFixer?

[Ticker Berkin]

Hi

First of all did you have these values in AngleChecker
  COMPACT_DIR_DEGREES = 45+1;
  SHARP_DEGREES = COMPACT_DIR_DEGREES;
If SHARP_DEGREES is less than this, then, with compactDir format, there might
not be big enough distinction between the directions of the 2 exit ways to get
the correct turn instruction. 

There isn't any flags or road matching to see which is the most likely
continuation and which is the turn off.

As far as I know, the turn instructions are just based on the AngleOfTurn.

Before my change this week it just looked at the highway class and speed and, if
different, adjusted the lower one in preference, and, if all else equal,
adjusted both.

My change this week is just based on one of the angles between arcs being
between 177 and 183 degrees and, if so, not changing these arcs. With a bit more
complication I could also try matching the way IDs.

Your second example isn't quite clear; there are 3 3-way junctions near the
coords you gave, and, for one of them, the continuous way bends with the other
way, starting at the node, almost straight on going south. Without loading these
nodes and checking all the initial headings I can't tell which angles are
"sharp" and AngleChecker doesn't do anything if there are no sharp angles. 

Regards
Ticker

On Thu, 2024-08-08 at 15:11 +0200, Thorsten Kukuk wrote:
> 
> Hi,
> 
> Am 2024-08-08 14:22, schrieb Ticker Berkin:
> > Hi Thorsten
> > 
> > Is the problem still with node https://www.osm.org/node/27550903 and 
> > ways
> > 36138336 / 144732811
> 
> Yes. That's one.
> Else see below.
> 
> > I've loaded this example and looked at the angles before and after 
> > adjustment
> > with my patch. From the south the way enters the node with heading 
> > 161.6 and
> > leaves with heading -16, giving an angle of 178.6 (almost straight). 
> > The other
> > way leaves with heading -32.4, giving a sharp angle of 15.4 degrees 
> > that the
> > logic will want to increase.
> > 
> > After the adjustments, the main way isn't changed and the other way is 
> > given a
> > new heading of -63 degrees.
> > 
> > In compactDir format the main way enters in seg 7 and leaves in seg 15 
> > (direct
> > opposite) and the other way now leaves in seg 13 (a clear segment 
> > between the
> > other exit). This, I thought, would be enough to get the turn 
> > instruction on the
> > correct road.
> > 
> > I've forgotten how some of the forward and reverse arc stuff works and, 
> > if there
> > is still a problem, I need to re-understand it to make sure that the
> > manipulations that we do to the angles at a node make sense for all 
> > routes
> > through it
> 
> I don't know anything about the format.
> Is there somehow a flag what is the main road, or is this navigation 
> instruction purely based on the degree of the turn?
> Because, I have more similar situations like here:
> https://www.openstreetmap.org/#map=18/49.43041/10.99213
> 
> If you go from north to the south and have to turn right no instruction 
> is coming, if you have to go straight forward, a "turn left" is coming.
> Difference to the point above is, that the main road is make a turn 
> right and the straight forward is a new, smaller way.
> 
> Regards,
> Thorsten
> 
> > Ticker
> > 
> > PS: no ideal about your mail error
> > 
> > 
> > On Thu, 2024-08-08 at 11:45 +0200, Thorsten Kukuk wrote:
> > > 
> > > Hi,
> > > 
> > > trying from another email account, with the other I always get an 
> > > error
> > > when trying to send to the mailing list:
> > > TLS Negotiation failed: FAILED_PRECONDITION: starttls error (71):
> > > 123617668315712:error:112e:SSL
> > > routines:OPENSSL_internal:KEY_USAGE_BIT_INCORRECT:third_party/openssl/bori
> > > ngss
> > > l/src/ssl/ssl_cert.cc:431:
> > > 
> > > 
> > > I tried the patch from Ticker, it fixes routing problems with sharp
> > > angles for me,
> > > where previously Garmin devices would avoid the Junction.
> > > But it does not fix the wrong turn instruction for me.
> > > 
> > > Regards,
> > > Thorsten
> > 
> > ___
> > 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] Problem in AngleFixer?

[Thorsten Kukuk]

Am 2024-08-08 16:52, schrieb Ticker Berkin:

Hi

First of all did you have these values in AngleChecker
  COMPACT_DIR_DEGREES = 45+1;
  SHARP_DEGREES = COMPACT_DIR_DEGREES;
If SHARP_DEGREES is less than this, then, with compactDir format, there 
might
not be big enough distinction between the directions of the 2 exit ways 
to get

the correct turn instruction.


Yes, I haven't changed them. I'm using mkgmap r4921 with your patch.

Your second example isn't quite clear; there are 3 3-way junctions near 
the
coords you gave, and, for one of them, the continuous way bends with 
the other
way, starting at the node, almost straight on going south. Without 
loading these
nodes and checking all the initial headings I can't tell which angles 
are
"sharp" and AngleChecker doesn't do anything if there are no sharp 
angles.


The point is https://www.openstreetmap.org/node/261582603
The ways are https://www.openstreetmap.org/way/24147681 and 
https://www.openstreetmap.org/way/24147729


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

Re: [mkgmap-dev] Problem in AngleFixer?

[Ticker Berkin]

Hi Thorsten

I don't see an easy solution to your second example, the "turn-off" is almost
straight on.

I don't understand why my change didn't fix your first example, unless you
allocate different road speed/class for different smoothness, surface, tracktype
tags, in which case the continuous way might be lower priority than the joining
way and the algorithm prefers to this.

Regards
Ticker 

On Thu, 2024-08-08 at 17:11 +0200, Thorsten Kukuk wrote:
> Am 2024-08-08 16:52, schrieb Ticker Berkin:
> > Hi
> > 
> > First of all did you have these values in AngleChecker
> >   COMPACT_DIR_DEGREES = 45+1;
> >   SHARP_DEGREES = COMPACT_DIR_DEGREES;
> > If SHARP_DEGREES is less than this, then, with compactDir format, there 
> > might
> > not be big enough distinction between the directions of the 2 exit ways 
> > to get
> > the correct turn instruction.
> 
> Yes, I haven't changed them. I'm using mkgmap r4921 with your patch.
> 
> > Your second example isn't quite clear; there are 3 3-way junctions near 
> > the
> > coords you gave, and, for one of them, the continuous way bends with 
> > the other
> > way, starting at the node, almost straight on going south. Without 
> > loading these
> > nodes and checking all the initial headings I can't tell which angles 
> > are
> > "sharp" and AngleChecker doesn't do anything if there are no sharp 
> > angles.
> 
> The point is https://www.openstreetmap.org/node/261582603
> The ways are https://www.openstreetmap.org/way/24147681 and 
> https://www.openstreetmap.org/way/24147729
> 
> Thorsten
> ___
> 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] Problem in AngleFixer?

[Thorsten Kukuk]

Hi Ticker,

Am 2024-08-09 12:48, schrieb Ticker Berkin:

Hi Thorsten

I don't see an easy solution to your second example, the "turn-off" is 
almost

straight on.

I don't understand why my change didn't fix your first example, unless 
you
allocate different road speed/class for different smoothness, surface, 
tracktype
tags, in which case the continuous way might be lower priority than the 
joining

way and the algorithm prefers to this.


To get that right: Your patch fixes one half of my first example: if you 
let Garmin calculate the route, it will now use the junction and will 
not use u-turns and detours to avoid it. So your patch is an 
improvement.
What it does not fix is the wrong navigation instruction: it tells you 
to turn right if you need to go straight forward, and if you need to 
turn left it doesn't tell you anything. And this shouldn't have anything 
to do with road speed or surface.


Beside for the tests I made sure that road speed and everything else is 
identical.


Regards,
  Thorsten


Regards
Ticker

On Thu, 2024-08-08 at 17:11 +0200, Thorsten Kukuk wrote:

Am 2024-08-08 16:52, schrieb Ticker Berkin:
> Hi
>
> First of all did you have these values in AngleChecker
>   COMPACT_DIR_DEGREES = 45+1;
>   SHARP_DEGREES = COMPACT_DIR_DEGREES;
> If SHARP_DEGREES is less than this, then, with compactDir format, there
> might
> not be big enough distinction between the directions of the 2 exit ways
> to get
> the correct turn instruction.

Yes, I haven't changed them. I'm using mkgmap r4921 with your patch.

> Your second example isn't quite clear; there are 3 3-way junctions near
> the
> coords you gave, and, for one of them, the continuous way bends with
> the other
> way, starting at the node, almost straight on going south. Without
> loading these
> nodes and checking all the initial headings I can't tell which angles
> are
> "sharp" and AngleChecker doesn't do anything if there are no sharp
> angles.

The point is https://www.openstreetmap.org/node/261582603
The ways are https://www.openstreetmap.org/way/24147681 and
https://www.openstreetmap.org/way/24147729

Thorsten
___
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] Problem in AngleFixer?

[Ticker Berkin]

Hi Thorsten

The algorithm, in choosing which arc headings to adjust to remove sharp turns,
prefers to adjust lower class roads. If class is the same it adjusts lower speed
road. If these are the same, with my change it, it sees if one is reasonably
straight and adjusts the other. As a last resort it adjusts both.

This, I consider, is reasonable and gives good results almost all the time.

With the default style both ways have speed=1 class=0 and so it adjusts way
144732811. However if your style gives them different classes/speeds (144732811
is paved, the other is unpaved) it will bend way 36138336 such that this might
trigger a right-turn instruction if going from south to north.

I'm not sure what the best solution is for your example.

Regards
Ticker

On Sat, 2024-08-10 at 10:01 +0200, Thorsten Kukuk wrote:
> Am 2024-08-10 09:39, schrieb Thorsten Kukuk:
> 
> > To get that right: Your patch fixes one half of my first example: if 
> > you let Garmin calculate the route, it will now use the junction and 
> > will not use u-turns and detours to avoid it. So your patch is an 
> > improvement.
> > What it does not fix is the wrong navigation instruction: it tells you 
> > to turn right if you need to go straight forward, and if you need to 
> > turn left it doesn't tell you anything. And this shouldn't have 
> > anything to do with road speed or surface.
> 
> Maybe pictures explain it better:
> 
> 1. routing-no-patch.png is vanilla mkgmap r4921, Garmin makes two 
> forbidden u-turns and a detour and avoids the junction.
> 2. routing-with-patch.png is mkgrmap r4921 with your patch, Garmin uses 
> the junction.
> 3. navigation-instruction-turn-right.png: at the junction with a route 
> straight forward Garmin Software and Devices tell you to turn right in 
> navigation mode.
> 
> I hope this explains it better.
> 
> Regards,
> Thorsten
> 
> ___
> 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] Problem in AngleFixer?

[Ticker Berkin]

Hi Thorsten

Let me know if the road_speed and/or road_class are different with the style you
are using. If they are all the same I don't understand why it should give a turn
instruction.

If it is just the road_speed, I'll do another patch that prioritises road_class,
then "likely same road", then road_speed.

Ticker

On Sat, 2024-08-10 at 16:27 +0100, Ticker Berkin wrote:
> Hi Thorsten
> 
> The algorithm, in choosing which arc headings to adjust to remove sharp turns,
> prefers to adjust lower class roads. If class is the same it adjusts lower
> speed
> road. If these are the same, with my change it, it sees if one is reasonably
> straight and adjusts the other. As a last resort it adjusts both.
> 
> This, I consider, is reasonable and gives good results almost all the time.
> 
> With the default style both ways have speed=1 class=0 and so it adjusts way
> 144732811. However if your style gives them different classes/speeds
> (144732811
> is paved, the other is unpaved) it will bend way 36138336 such that this might
> trigger a right-turn instruction if going from south to north.
> 
> I'm not sure what the best solution is for your example.
> 
> Regards
> Ticker
> 
> On Sat, 2024-08-10 at 10:01 +0200, Thorsten Kukuk wrote:
> > Am 2024-08-10 09:39, schrieb Thorsten Kukuk:
> > 
> > > To get that right: Your patch fixes one half of my first example: if 
> > > you let Garmin calculate the route, it will now use the junction and 
> > > will not use u-turns and detours to avoid it. So your patch is an 
> > > improvement.
> > > What it does not fix is the wrong navigation instruction: it tells you 
> > > to turn right if you need to go straight forward, and if you need to 
> > > turn left it doesn't tell you anything. And this shouldn't have 
> > > anything to do with road speed or surface.
> > 
> > Maybe pictures explain it better:
> > 
> > 1. routing-no-patch.png is vanilla mkgmap r4921, Garmin makes two 
> > forbidden u-turns and a detour and avoids the junction.
> > 2. routing-with-patch.png is mkgrmap r4921 with your patch, Garmin uses 
> > the junction.
> > 3. navigation-instruction-turn-right.png: at the junction with a route 
> > straight forward Garmin Software and Devices tell you to turn right in 
> > navigation mode.
> > 
> > I hope this explains it better.
> > 
> > Regards,
> > Thorsten
> > 
> > ___
> > 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] Problem in AngleFixer?

[Thorsten Kukuk]

Hi Ticker,

The way straight forward is
https://www.openstreetmap.org/way/36138336

It's one long way in OSM, which means all tags before and after the 
junction are the same:

road_class=1 and road_speed=2

The way starting at the junction to the left is 
https://www.openstreetmap.org/way/144732811 and has

road_class=2 and road_speed=2 in my style.

Regards,
Thorsten

Am 2024-08-10 18:38, schrieb Ticker Berkin:

Hi Thorsten

Let me know if the road_speed and/or road_class are different with the 
style you
are using. If they are all the same I don't understand why it should 
give a turn

instruction.

If it is just the road_speed, I'll do another patch that prioritises 
road_class,

then "likely same road", then road_speed.

Ticker

On Sat, 2024-08-10 at 16:27 +0100, Ticker Berkin wrote:

Hi Thorsten

The algorithm, in choosing which arc headings to adjust to remove 
sharp turns,
prefers to adjust lower class roads. If class is the same it adjusts 
lower

speed
road. If these are the same, with my change it, it sees if one is 
reasonably

straight and adjusts the other. As a last resort it adjusts both.

This, I consider, is reasonable and gives good results almost all the 
time.


With the default style both ways have speed=1 class=0 and so it 
adjusts way

144732811. However if your style gives them different classes/speeds
(144732811
is paved, the other is unpaved) it will bend way 36138336 such that 
this might

trigger a right-turn instruction if going from south to north.

I'm not sure what the best solution is for your example.

Regards
Ticker

On Sat, 2024-08-10 at 10:01 +0200, Thorsten Kukuk wrote:
> Am 2024-08-10 09:39, schrieb Thorsten Kukuk:
>
> > To get that right: Your patch fixes one half of my first example: if
> > you let Garmin calculate the route, it will now use the junction and
> > will not use u-turns and detours to avoid it. So your patch is an
> > improvement.
> > What it does not fix is the wrong navigation instruction: it tells you
> > to turn right if you need to go straight forward, and if you need to
> > turn left it doesn't tell you anything. And this shouldn't have
> > anything to do with road speed or surface.
>
> Maybe pictures explain it better:
>
> 1. routing-no-patch.png is vanilla mkgmap r4921, Garmin makes two
> forbidden u-turns and a detour and avoids the junction.
> 2. routing-with-patch.png is mkgrmap r4921 with your patch, Garmin uses
> the junction.
> 3. navigation-instruction-turn-right.png: at the junction with a route
> straight forward Garmin Software and Devices tell you to turn right in
> navigation mode.
>
> I hope this explains it better.
>
> Regards,
> Thorsten
>
> ___
> 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] Problem in AngleFixer?

[Ticker Berkin]

Hi Thorsten

Ah, the different road_class your style is generating would explain why my
change didn't work for you.

I started looking at the order in which to consider:
 road_class, sameWay, straightEnough, sameName, road_speed
and, in a typical area looking for conflict between these, came to the
conclusion that road_class should be first, which is unfortunate for your first
case.

I'll implement it a bit more and look at examples and see if they really matter.

Introducing "sameWay" might fix your second example.

Regards
Ticker

On Mon, 2024-08-12 at 10:23 +0200, Thorsten Kukuk wrote:
> 
> Hi Ticker,
> 
> The way straight forward is
> https://www.openstreetmap.org/way/36138336
> 
> It's one long way in OSM, which means all tags before and after the 
> junction are the same:
> road_class=1 and road_speed=2
> 
> The way starting at the junction to the left is 
> https://www.openstreetmap.org/way/144732811 and has
> road_class=2 and road_speed=2 in my style.
> 
> Regards,
> Thorsten
> 
> Am 2024-08-10 18:38, schrieb Ticker Berkin:
> > Hi Thorsten
> > 
> > Let me know if the road_speed and/or road_class are different with the 
> > style you
> > are using. If they are all the same I don't understand why it should 
> > give a turn
> > instruction.
> > 
> > If it is just the road_speed, I'll do another patch that prioritises 
> > road_class,
> > then "likely same road", then road_speed.
> > 
> > Ticker
> > 
> > On Sat, 2024-08-10 at 16:27 +0100, Ticker Berkin wrote:
> > > Hi Thorsten
> > > 
> > > The algorithm, in choosing which arc headings to adjust to remove 
> > > sharp turns,
> > > prefers to adjust lower class roads. If class is the same it adjusts 
> > > lower
> > > speed
> > > road. If these are the same, with my change it, it sees if one is 
> > > reasonably
> > > straight and adjusts the other. As a last resort it adjusts both.
> > > 
> > > This, I consider, is reasonable and gives good results almost all the 
> > > time.
> > > 
> > > With the default style both ways have speed=1 class=0 and so it 
> > > adjusts way
> > > 144732811. However if your style gives them different classes/speeds
> > > (144732811
> > > is paved, the other is unpaved) it will bend way 36138336 such that 
> > > this might
> > > trigger a right-turn instruction if going from south to north.
> > > 
> > > I'm not sure what the best solution is for your example.
> > > 
> > > Regards
> > > Ticker
> > > 
> > > On Sat, 2024-08-10 at 10:01 +0200, Thorsten Kukuk wrote:
> > > > Am 2024-08-10 09:39, schrieb Thorsten Kukuk:
> > > > 
> > > > > To get that right: Your patch fixes one half of my first example: if
> > > > > you let Garmin calculate the route, it will now use the junction and
> > > > > will not use u-turns and detours to avoid it. So your patch is an
> > > > > improvement.
> > > > > What it does not fix is the wrong navigation instruction: it tells you
> > > > > to turn right if you need to go straight forward, and if you need to
> > > > > turn left it doesn't tell you anything. And this shouldn't have
> > > > > anything to do with road speed or surface.
> > > > 
> > > > Maybe pictures explain it better:
> > > > 
> > > > 1. routing-no-patch.png is vanilla mkgmap r4921, Garmin makes two
> > > > forbidden u-turns and a detour and avoids the junction.
> > > > 2. routing-with-patch.png is mkgrmap r4921 with your patch, Garmin uses
> > > > the junction.
> > > > 3. navigation-instruction-turn-right.png: at the junction with a route
> > > > straight forward Garmin Software and Devices tell you to turn right in
> > > > navigation mode.
> > > > 
> > > > I hope this explains it better.
> > > > 
> > > > Regards,
> > > > Thorsten
> > > > 
> > > > ___
> > > > 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

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

Re: [mkgmap-dev] Problem in AngleFixer?

[Gerd Petermann]

Hi Ticker,

I also thought about sameWay as a criteria, but remember that this is likely to 
fail.
I see quite often that tracks are drawn with 90° angles and another one is 
added which also
has a 90° angle at the same crossing.  No idea why, but it isn't wrong.
Same situation in residential areas where multiple ways are needed but all have 
the same name
and type (e.g. a paved living_street).

ciao
Gerd


Von: mkgmap-dev  im Auftrag von Ticker 
Berkin 
Gesendet: Montag, 12. August 2024 10:42
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Problem in AngleFixer?

Hi Thorsten

Ah, the different road_class your style is generating would explain why my
change didn't work for you.

I started looking at the order in which to consider:
 road_class, sameWay, straightEnough, sameName, road_speed
and, in a typical area looking for conflict between these, came to the
conclusion that road_class should be first, which is unfortunate for your first
case.

I'll implement it a bit more and look at examples and see if they really matter.

Introducing "sameWay" might fix your second example.

Regards
Ticker

On Mon, 2024-08-12 at 10:23 +0200, Thorsten Kukuk wrote:
>
> Hi Ticker,
>
> The way straight forward is
> https://www.openstreetmap.org/way/36138336
>
> It's one long way in OSM, which means all tags before and after the
> junction are the same:
> road_class=1 and road_speed=2
>
> The way starting at the junction to the left is
> https://www.openstreetmap.org/way/144732811 and has
> road_class=2 and road_speed=2 in my style.
>
> Regards,
> Thorsten
>
> Am 2024-08-10 18:38, schrieb Ticker Berkin:
> > Hi Thorsten
> >
> > Let me know if the road_speed and/or road_class are different with the
> > style you
> > are using. If they are all the same I don't understand why it should
> > give a turn
> > instruction.
> >
> > If it is just the road_speed, I'll do another patch that prioritises
> > road_class,
> > then "likely same road", then road_speed.
> >
> > Ticker
> >
> > On Sat, 2024-08-10 at 16:27 +0100, Ticker Berkin wrote:
> > > Hi Thorsten
> > >
> > > The algorithm, in choosing which arc headings to adjust to remove
> > > sharp turns,
> > > prefers to adjust lower class roads. If class is the same it adjusts
> > > lower
> > > speed
> > > road. If these are the same, with my change it, it sees if one is
> > > reasonably
> > > straight and adjusts the other. As a last resort it adjusts both.
> > >
> > > This, I consider, is reasonable and gives good results almost all the
> > > time.
> > >
> > > With the default style both ways have speed=1 class=0 and so it
> > > adjusts way
> > > 144732811. However if your style gives them different classes/speeds
> > > (144732811
> > > is paved, the other is unpaved) it will bend way 36138336 such that
> > > this might
> > > trigger a right-turn instruction if going from south to north.
> > >
> > > I'm not sure what the best solution is for your example.
> > >
> > > Regards
> > > Ticker
> > >
> > > On Sat, 2024-08-10 at 10:01 +0200, Thorsten Kukuk wrote:
> > > > Am 2024-08-10 09:39, schrieb Thorsten Kukuk:
> > > >
> > > > > To get that right: Your patch fixes one half of my first example: if
> > > > > you let Garmin calculate the route, it will now use the junction and
> > > > > will not use u-turns and detours to avoid it. So your patch is an
> > > > > improvement.
> > > > > What it does not fix is the wrong navigation instruction: it tells you
> > > > > to turn right if you need to go straight forward, and if you need to
> > > > > turn left it doesn't tell you anything. And this shouldn't have
> > > > > anything to do with road speed or surface.
> > > >
> > > > Maybe pictures explain it better:
> > > >
> > > > 1. routing-no-patch.png is vanilla mkgmap r4921, Garmin makes two
> > > > forbidden u-turns and a detour and avoids the junction.
> > > > 2. routing-with-patch.png is mkgrmap r4921 with your patch, Garmin uses
> > > > the junction.
> > > > 3. navigation-instruction-turn-right.png: at the junction with a route
> > > > straight forward Garmin Software and Devices tell you to turn right in
> > > > navigation mode.
> > > >
> > > > I hope this explains it better.
> > > >

Re: [mkgmap-dev] Problem in AngleFixer?

[Ticker Berkin]

Hi Thorsten and Gerd

I've looked at examples around my area where a higher class way terminates (at a
sharp angle) in the middle of a way or 2 straight ways and, in none that I
found, would it be a problem to adjust the angle of the higher class road.

I've re-done the patch to this effect, also adding in test for sameName arcs and
simplifying the logic slightly such that it is easier to change the testing
order.

@Thorsten: can you try this; it should fix your first example. It might fix the
second but, because the continuous way has quite an angle at the junction, even
moving the turn-off road away from it might not be enough to trigger the turn-
instruction.

@Gerd: The new logic doesn't attempt to handle roads crossing. For
straightEnough it just looks at the angle either side of the sharp angle. For
sameWay and sameRoad it just looks at the adjacent arcs either side of the sharp
angle. For 3 arc junctions this is correct but for 4 or more arcs it might help
but is not complete.

I'm going to use this for a while.

There are some diags that could be removed later.

Regards
Ticker

On Mon, 2024-08-12 at 09:34 +, Gerd Petermann wrote:
> Hi Ticker,
> 
> I also thought about sameWay as a criteria, but remember that this is likely
> to fail.
> I see quite often that tracks are drawn with 90° angles and another one is
> added which also
> has a 90° angle at the same crossing.  No idea why, but it isn't wrong.
> Same situation in residential areas where multiple ways are needed but all
> have the same name
> and type (e.g. a paved living_street).
> 
> ciao
> Gerd

Index: src/uk/me/parabola/imgfmt/app/net/AngleChecker.java
===
--- src/uk/me/parabola/imgfmt/app/net/AngleChecker.java	(revision 4921)
+++ src/uk/me/parabola/imgfmt/app/net/AngleChecker.java	(working copy)
@@ -68,8 +68,9 @@
 	// If this is >= above, then compactDirs will be used unless other, non-vehicle access angles are sharp
 	private static final float SHARP_DEGREES = COMPACT_DIR_DEGREES;
 	// Experimentation found no benefit in increasing angle beyond 2 "sectors"
-	private static final float MIN_ANGLE = 11.25f; // don't reduce angles to less than this (arbitrary)
-	
+	private static final float MIN_ANGLE = 23f; // don't reduce angles to less than this (1 sector + bit)
+	private static final float STRAIGHT_EPSILON = 3f; // for angle.straightAnough()
+
 	// helper class to collect multiple arcs with (nearly) the same initial headings
 	private class ArcGroup {
 		float initialHeading;
@@ -106,7 +107,27 @@
 		public boolean isForward() {
 			return isForwardTrueCount == arcs.size();
 		}
-		
+
+		public boolean sameWay(ArcGroup other) {
+			for (RoadDef thisRoad : roadDefs)
+for (RoadDef otherRoad : other.roadDefs) {
+	if (thisRoad.getId() == otherRoad.getId())
+		return true;
+}
+			return false;
+		}
+
+		public boolean sameName(ArcGroup other) {
+			for (RoadDef thisRoad : roadDefs)
+for (RoadDef otherRoad : other.roadDefs) {
+	String thisName = thisRoad.getName();
+	if (thisName != null)
+		if (thisName.equals(otherRoad.getName()))
+			return true;
+}
+			return false;
+		}
+
 		public void modInitialHeading(float modIH) {
 			initialHeading += modIH;
 			if (initialHeading >= 180)
@@ -116,6 +137,7 @@
 
 			for (RouteArc arc : arcs) {
 arc.modInitialHeading(modIH);
+log.info("modInitHead", arc, modIH, initialHeading);
 			}
 		}
 
@@ -152,12 +174,20 @@
 
 		// Combine arcs with nearly the same initial heading.
 
+		if (log.isInfoEnabled())
+			log.info("fixSharpAngles", node, sharpAnglesCheckMask, arcs.size());
+
 		// first get direct arcs leaving the node
 		List directArcs = new ArrayList<>();
 		for (RouteArc arc : arcs) {
-			if (arc.isDirect())
+			if (arc.isDirect()) {
+if (log.isInfoEnabled()) {
+	RoadDef rd = arc.getRoadDef();
+	log.info("directArc", /*arc,*/ arc.getInitialHeading(), rd.getId(), rd.getName(),
+			 rd.getRoadSpeed(), rd.getRoadClass(), rd.paved());
+}
 directArcs.add(arc);
-			else
+			} else
 // AngleChecker runs before addArcsToMajorRoads so there shouldn't be any indirect arcs yet.
 // If this changes, extra care needs to be taken check they are positioned correctly in the list
 // of arcs or that their heading is kept consistent with changes to their direct base arc.
@@ -237,6 +267,11 @@
 		class AngleAttr {
 			float angle;
 			float minAngle;
+
+			private boolean straightAnough() {
+return angle > 180-STRAIGHT_EPSILON && angle < 180+STRAIGHT_EPSILON;
+			}
+
 		}
 
 		AngleAttr[] angles = new AngleAttr[n];
@@ -249,6 +284,8 @@
 			if (i+1 >= n)
 aa.angle += 360;
 			aa.minAngle = Math.min(MIN_ANGLE, aa.angle);
+			log.info("AngleCalc", node, ag1.getInitialHeading(), aa.angle, ag2.getInitialHeading(), aa.minAngle);
+
 			float saveMinAngle = aa.minAngle;
 
 			if (ag1.isOneway() && ag2.isOneway() && (ag1.isForward() == ag2.isForward()))
@@ -317,8 +354,10 @

Re: [mkgmap-dev] Problem in AngleFixer?

[Ticker Berkin]

Really sorry, previous patch was wrong. Correct one attached

Ticker

Index: src/uk/me/parabola/imgfmt/app/net/AngleChecker.java
===
--- src/uk/me/parabola/imgfmt/app/net/AngleChecker.java	(revision 4921)
+++ src/uk/me/parabola/imgfmt/app/net/AngleChecker.java	(working copy)
@@ -68,8 +68,9 @@
 	// If this is >= above, then compactDirs will be used unless other, non-vehicle access angles are sharp
 	private static final float SHARP_DEGREES = COMPACT_DIR_DEGREES;
 	// Experimentation found no benefit in increasing angle beyond 2 "sectors"
-	private static final float MIN_ANGLE = 11.25f; // don't reduce angles to less than this (arbitrary)
-	
+	private static final float MIN_ANGLE = 23f; // don't reduce angles to less than this (1 sector + bit)
+	private static final float STRAIGHT_EPSILON = 3f; // for angle.straightAnough()
+
 	// helper class to collect multiple arcs with (nearly) the same initial headings
 	private class ArcGroup {
 		float initialHeading;
@@ -106,7 +107,27 @@
 		public boolean isForward() {
 			return isForwardTrueCount == arcs.size();
 		}
-		
+
+		public boolean sameWay(ArcGroup other) {
+			for (RoadDef thisRoad : roadDefs)
+for (RoadDef otherRoad : other.roadDefs) {
+	if (thisRoad.getId() == otherRoad.getId())
+		return true;
+}
+			return false;
+		}
+
+		public boolean sameName(ArcGroup other) {
+			for (RoadDef thisRoad : roadDefs)
+for (RoadDef otherRoad : other.roadDefs) {
+	String thisName = thisRoad.getName();
+	if (thisName != null)
+		if (thisName.equals(otherRoad.getName()))
+			return true;
+}
+			return false;
+		}
+
 		public void modInitialHeading(float modIH) {
 			initialHeading += modIH;
 			if (initialHeading >= 180)
@@ -116,6 +137,7 @@
 
 			for (RouteArc arc : arcs) {
 arc.modInitialHeading(modIH);
+log.info("modInitHead", arc, modIH, initialHeading);
 			}
 		}
 
@@ -152,12 +174,20 @@
 
 		// Combine arcs with nearly the same initial heading.
 
+		if (log.isInfoEnabled())
+			log.info("fixSharpAngles", node, sharpAnglesCheckMask, arcs.size());
+
 		// first get direct arcs leaving the node
 		List directArcs = new ArrayList<>();
 		for (RouteArc arc : arcs) {
-			if (arc.isDirect())
+			if (arc.isDirect()) {
+if (log.isInfoEnabled()) {
+	RoadDef rd = arc.getRoadDef();
+	log.info("directArc", /*arc,*/ arc.getInitialHeading(), rd.getId(), rd.getName(),
+			 rd.getRoadSpeed(), rd.getRoadClass(), rd.paved());
+}
 directArcs.add(arc);
-			else
+			} else
 // AngleChecker runs before addArcsToMajorRoads so there shouldn't be any indirect arcs yet.
 // If this changes, extra care needs to be taken check they are positioned correctly in the list
 // of arcs or that their heading is kept consistent with changes to their direct base arc.
@@ -237,6 +267,11 @@
 		class AngleAttr {
 			float angle;
 			float minAngle;
+
+			private boolean straightAnough() {
+return angle > 180-STRAIGHT_EPSILON && angle < 180+STRAIGHT_EPSILON;
+			}
+
 		}
 
 		AngleAttr[] angles = new AngleAttr[n];
@@ -249,6 +284,8 @@
 			if (i+1 >= n)
 aa.angle += 360;
 			aa.minAngle = Math.min(MIN_ANGLE, aa.angle);
+			log.info("AngleCalc", node, ag1.getInitialHeading(), aa.angle, ag2.getInitialHeading(), aa.minAngle);
+
 			float saveMinAngle = aa.minAngle;
 
 			if (ag1.isOneway() && ag2.isOneway() && (ag1.isForward() == ag2.isForward()))
@@ -317,8 +354,10 @@
 			if (wantedIncrement <= 0)
 continue;
 			float oldAngle = aa.angle;
+			ArcGroup ag0 = null;
 			ArcGroup ag1 = arcGroups.get(i);
 			ArcGroup ag2 = arcGroups.get(i+1 < n ? i+1 : 0);
+			ArcGroup ag3 = null;
 			if (log.isInfoEnabled()){
 log.info("sharp angle", aa.angle, "° at", node.getCoord(),
 		 "headings", getCompassBearing(ag1.getInitialHeading()), getCompassBearing(ag2.getInitialHeading()),
@@ -336,13 +375,47 @@
 			float deltaNext = nextAA.angle - nextAA.minAngle;
 
 			if (deltaNext > 0 && deltaPred > 0) { // can take from both
-if (ag1.maxRoadClass == ag2.maxRoadClass &&
-	ag1.maxRoadSpeed == ag2.maxRoadSpeed) { // take from both in ratio to available
+int chooseWhich = 0; // -ve to prefer to take from prev, +ve take from next
+// order of {road_class, sameWay, straightness, roadName, road_speed} adjusted for priority
+// Hoping sameWay before road_class fixing more problems than it might cause
+if (chooseWhich == 0) {
+	// if the two arcs either side of the sharp angle belong to the same
+	// way then change the arc on the other side hoping to trigger
+	// the correct turn-instruction
+	ag0 = arcGroups.get(i > 0 ? i-1 : n-1);
+	ag3 = n == 3 ? ag0 : arcGroups.get(i+2 < n ? i+2 : i+2-n);
+	if (ag2.sameWay(ag3))
+		chooseWhich = -1;
+	else if (ag1.sameWay(ag0))
+		chooseWhich = +1;
+}
+if (chooseWhich == 0)
+	chooseWhich = ag1.maxRoadClass - ag2.maxRoadClass;
+if (chooseWhich == 0) {
+	// whe

Re: [mkgmap-dev] Problem in AngleFixer?

[Thorsten Kukuk]

Hi Ticker,

Am 2024-08-12 13:14, schrieb Ticker Berkin:

Really sorry, previous patch was wrong. Correct one attached


Sorry, but for https://www.openstreetmap.org/#map=18/49.47851/10.94281 
this has still no effect.

But I think I found the problem.

The part from the log file is:
sharp angle 15.375715 ° at 49.478507,10.942814 headings 328° 343° speeds 
2 2 classes 2 1

increasing arc with heading 343° by 30.624285

The other sharp angle a few meters away 
(https://www.openstreetmap.org/#map=19/49.47966/10.94146),

which works, has:
sharp angle 40.094727 ° at 49.479659,10.941464 headings 132° 172° speeds 
2 2 classes 2 2

increasing arc with heading 172° by 2.3486972
decreasing arc with heading 132° by 3.5565763

Difference: in the first case, the heading is >> 180°
In the second case, it's < 180°.

So I did go through the log and tested some more cases:
If the heading is >> 180°, the navigation instruction is wrong.
If the heading is < 180°, the navigation instruction is correct.

Looks like if an angle is >> 180°, we have to code another one in the 
map.


Regards,
Thorsten


Ticker


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

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

Re: [mkgmap-dev] Problem in AngleFixer?

[Ticker Berkin]

Hi Thorsten

This is different from what I'm getting (after adjustments to get compatible
class & speed):

sharp angle 15.375715 ° at 49.478507,10.942814 headings 328° 343° speeds 3 3
classes 2 1
decreasing arc with heading 328° by 30.624285

Can you check {yourbase}/src/uk/me/parabola/imgfmt/app/net/AngleChecker.java
around line 379 you have:
<<<
// Hoping sameWay before road_class fixing more problems than it might cause
if (chooseWhich == 0) {
// if the two arcs either side of the sharp angle belong to the same
// way then change the arc on the other side hoping to trigger
// the correct turn-instruction
ag0 = arcGroups.get ...
ag3 = n == 3 ? ...
if (ag2.sameWay(ag3))
chooseWhich = -1;
else if (ag1.sameWay(ag0))
chooseWhich = +1;
}
if (chooseWhich == 0)
chooseWhich = ag1.maxRoadClass - ag2.maxRoadClass;
>>>
as from AngleChecker_v3.patch and this is the version you've build and tested.

If it is all correct then I'll need to add more diagnostics to see if the
internal ways have been manipulated.

Concerning the second example, I hope we've got good and consistent
representations of all the RouteNode angles in the two formats in the garmin
.img file and, generally, we get the turn-instructions expected but we don't
know the rules for these.

Your examples where the turn-instructions are not what you expect are explicable
because the other road is more straight-on than the way continuation.
AngleChecker sometimes made this worse when giving junction RouteNode geometry
that is different from reality to avoid garmin applying massive time penalties
to some turns.

Regards
Ticker

On Tue, 2024-08-13 at 17:06 +0200, Thorsten Kukuk wrote:
> 
> Hi Ticker,
> 
> Am 2024-08-12 13:14, schrieb Ticker Berkin:
> > Really sorry, previous patch was wrong. Correct one attached
> 
> Sorry, but for https://www.openstreetmap.org/#map=18/49.47851/10.94281 
> this has still no effect.
> But I think I found the problem.
> 
> The part from the log file is:
> sharp angle 15.375715 ° at 49.478507,10.942814 headings 328° 343° speeds 
> 2 2 classes 2 1
> increasing arc with heading 343° by 30.624285
> 
> The other sharp angle a few meters away 
> (https://www.openstreetmap.org/#map=19/49.47966/10.94146),
> which works, has:
> sharp angle 40.094727 ° at 49.479659,10.941464 headings 132° 172° speeds 
> 2 2 classes 2 2
> increasing arc with heading 172° by 2.3486972
> decreasing arc with heading 132° by 3.5565763
> 
> Difference: in the first case, the heading is >> 180°
> In the second case, it's < 180°.
> 
> So I did go through the log and tested some more cases:
> If the heading is >> 180°, the navigation instruction is wrong.
> If the heading is < 180°, the navigation instruction is correct.
> 
> Looks like if an angle is >> 180°, we have to code another one in the 
> map.
> 
> Regards,
> Thorsten
> 
> > Ticker
> > 
> > 
> > ___
> > mkgmap-dev mailing list
> > mkgmap-dev@lists.mkgmap.org.uk
> > https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> 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] Problem in AngleFixer?

[Thorsten Kukuk]

Hi Ticker,

The code is identical.

But: how do you explain, that on all junctions, where your logging 
reports headings
in the 3xx° area, Garmin navigation instructions are wrong, and where 
the
headings are < 180°, the navigation instructions are correct? In between 
it looks like, turn instructions for both directions are given.
And I don't speak here about the two junctions I brought up in this mail 
thread,
I selected several random junctions from the log file with "sharp angle" 
and created routes for it.
And for all, where the headings are in the 3xx° area, the notifications 
were "wrong", and in all, where

it was below 180°, it was correct.

Examples for "wrong" routing instructions:
sharp angle 13.183327 ° at 49.294696,11.107571 headings 307° 320° speeds 
2 2 classes 3 1

increasing arc with heading 320° by 32.816673

sharp angle 32.202377 ° at 49.445028,11.075047 headings 322° 354° speeds 
3 2 classes 1 3

decreasing arc with heading 322° by 13.797623

My observation:
headings below < 180° seem to be fine. Or I had always luck when 
testing.

headings around 270° seems to give you instructions for both directions.
headings in the 3xx° area will give you "wrong" instructions.

Regards,
Thorsten

Am 2024-08-13 18:57, schrieb Ticker Berkin:

Hi Thorsten

This is different from what I'm getting (after adjustments to get 
compatible

class & speed):

sharp angle 15.375715 ° at 49.478507,10.942814 headings 328° 343° 
speeds 3 3

classes 2 1
decreasing arc with heading 328° by 30.624285

Can you check 
{yourbase}/src/uk/me/parabola/imgfmt/app/net/AngleChecker.java

around line 379 you have:
<<<
// Hoping sameWay before road_class fixing more problems than it might 
cause

if (chooseWhich == 0) {
// if the two arcs either side of the sharp angle belong to the same
// way then change the arc on the other side hoping to trigger
// the correct turn-instruction
ag0 = arcGroups.get ...
ag3 = n == 3 ? ...
if (ag2.sameWay(ag3))
chooseWhich = -1;
else if (ag1.sameWay(ag0))
chooseWhich = +1;
}
if (chooseWhich == 0)
chooseWhich = ag1.maxRoadClass - ag2.maxRoadClass;


as from AngleChecker_v3.patch and this is the version you've build and 
tested.


If it is all correct then I'll need to add more diagnostics to see if 
the

internal ways have been manipulated.

Concerning the second example, I hope we've got good and consistent
representations of all the RouteNode angles in the two formats in the 
garmin
.img file and, generally, we get the turn-instructions expected but we 
don't

know the rules for these.

Your examples where the turn-instructions are not what you expect are 
explicable

because the other road is more straight-on than the way continuation.
AngleChecker sometimes made this worse when giving junction RouteNode 
geometry
that is different from reality to avoid garmin applying massive time 
penalties

to some turns.

Regards
Ticker

On Tue, 2024-08-13 at 17:06 +0200, Thorsten Kukuk wrote:


Hi Ticker,

Am 2024-08-12 13:14, schrieb Ticker Berkin:
> Really sorry, previous patch was wrong. Correct one attached

Sorry, but for 
https://www.openstreetmap.org/#map=18/49.47851/10.94281 

this has still no effect.
But I think I found the problem.

The part from the log file is:
sharp angle 15.375715 ° at 49.478507,10.942814 headings 328° 343° 
speeds

2 2 classes 2 1
increasing arc with heading 343° by 30.624285

The other sharp angle a few meters away
(https://www.openstreetmap.org/#map=19/49.47966/10.94146),
which works, has:
sharp angle 40.094727 ° at 49.479659,10.941464 headings 132° 172° 
speeds

2 2 classes 2 2
increasing arc with heading 172° by 2.3486972
decreasing arc with heading 132° by 3.5565763

Difference: in the first case, the heading is >> 180°
In the second case, it's < 180°.

So I did go through the log and tested some more cases:
If the heading is >> 180°, the navigation instruction is wrong.
If the heading is < 180°, the navigation instruction is correct.

Looks like if an angle is >> 180°, we have to code another one in the
map.

Regards,
Thorsten

> Ticker
>
>
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
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] Problem in AngleFixer?

[Ticker Berkin]

Hi Thorsten

I can't explain the turn instructions being in the wrong direction for some
ranges of angles. What are you seeing this on - Basecamp / MapSource / Garmin
Device?

At the moment I'm more concerned with why, for your first example, we get
different arcs being adjusted. I've added more diagnostics to show if the
continuous way has been split and been given different ids.

Can you send me the same sections of the log file, the first should look like
this:

fixSharpAngles_v4 at 49.478507,10.942814 mask 2 smallestAngle 15.375715 nArcs 3
nDirectArcs 3 nGroups 3
Arc heading -32.3756 328° angToPrev 166.0431 class 2 speed 3 way 144732811
isFake false rdDef 318472903 name null paved true
Arc heading -16.999884 343° angToPrev 15.375715 class 1 speed 3 way 36138336
isFake false rdDef 1286211837 name null paved true
Arc heading 161.5813 162° angToPrev 178.58118 class 1 speed 3 way 36138336
isFake false rdDef 1286211837 name null paved true
Angle 15.375715 between -32.3756 and -16.999884 minAngle 46.0 wantedInc
30.624285 deltaPred 120.043106 deltaNext 132.58118
decreasing arc with heading 328° by 30.624285
modInitialHeading arc from -32.3756 by -30.624285 to -62.999886

If, in this example, way 36138338 has been split, I need to see if there is any
way of finding the associated bits of road

Attached is new patch.

Regards
Ticker

On Tue, 2024-08-13 at 19:44 +0200, Thorsten Kukuk wrote:
> Hi Ticker,
> 
> The code is identical.
> 
> But: how do you explain, that on all junctions, where your logging 
> reports headings
> in the 3xx° area, Garmin navigation instructions are wrong, and where 
> the
> headings are < 180°, the navigation instructions are correct? In between 
> it looks like, turn instructions for both directions are given.
> And I don't speak here about the two junctions I brought up in this mail 
> thread,
> I selected several random junctions from the log file with "sharp angle" 
> and created routes for it.
> And for all, where the headings are in the 3xx° area, the notifications 
> were "wrong", and in all, where
> it was below 180°, it was correct.
> 
> Examples for "wrong" routing instructions:
> sharp angle 13.183327 ° at 49.294696,11.107571 headings 307° 320° speeds 
> 2 2 classes 3 1
> increasing arc with heading 320° by 32.816673
> 
> sharp angle 32.202377 ° at 49.445028,11.075047 headings 322° 354° speeds 
> 3 2 classes 1 3
> decreasing arc with heading 322° by 13.797623
> 
> My observation:
> headings below < 180° seem to be fine. Or I had always luck when 
> testing.
> headings around 270° seems to give you instructions for both directions.
> headings in the 3xx° area will give you "wrong" instructions.
> 
> Regards,
> Thorsten

Index: src/uk/me/parabola/imgfmt/app/net/AngleChecker.java
===
--- src/uk/me/parabola/imgfmt/app/net/AngleChecker.java	(revision 4921)
+++ src/uk/me/parabola/imgfmt/app/net/AngleChecker.java	(working copy)
@@ -20,6 +20,7 @@
 
 import uk.me.parabola.log.Logger;
 import uk.me.parabola.util.EnhancedProperties;
+import uk.me.parabola.mkgmap.reader.osm.FakeIdGenerator;
 
 /**
  * Find sharp angles at junctions. The Garmin routing algorithm doesn't
@@ -68,8 +69,9 @@
 	// If this is >= above, then compactDirs will be used unless other, non-vehicle access angles are sharp
 	private static final float SHARP_DEGREES = COMPACT_DIR_DEGREES;
 	// Experimentation found no benefit in increasing angle beyond 2 "sectors"
-	private static final float MIN_ANGLE = 11.25f; // don't reduce angles to less than this (arbitrary)
-	
+	private static final float MIN_ANGLE = 23f; // don't reduce angles to less than this (1 sector + bit)
+	private static final float STRAIGHT_EPSILON = 3f; // for angle.straightEnough()
+
 	// helper class to collect multiple arcs with (nearly) the same initial headings
 	private class ArcGroup {
 		float initialHeading;
@@ -106,7 +108,27 @@
 		public boolean isForward() {
 			return isForwardTrueCount == arcs.size();
 		}
-		
+
+		public boolean sameWay(ArcGroup other) {
+			for (RoadDef thisRoad : roadDefs)
+for (RoadDef otherRoad : other.roadDefs) {
+	if (thisRoad.getId() == otherRoad.getId())
+		return true;
+}
+			return false;
+		}
+
+		public boolean sameName(ArcGroup other) {
+			for (RoadDef thisRoad : roadDefs) {
+String thisName = thisRoad.getName();
+if (thisName != null)
+	for (RoadDef otherRoad : other.roadDefs)
+		if (thisName.equals(otherRoad.getName()))
+			return true;
+			}
+			return false;
+		}
+
 		public void modInitialHeading(float modIH) {
 			initialHeading += modIH;
 			if (initialHeading >= 180)
@@ -113,6 +135,7 @@
 initialHeading -= 360;
 			else if (initialHeading < -180)
 initialHeading += 360;
+			log.info("modInitialHeading arc from", arcs.get(0).getInitialHeading(), "by", modIH, "to", initialHeading);
 
 			for (RouteArc arc : arcs) {
 arc.modInitialHeading(modIH);
@@ -183,7 +206,7 @@
 		Iterator iter = directArcs

Re: [mkgmap-dev] Problem in AngleFixer?

[Thorsten Kukuk]

Hi Ticker,

Am 2024-08-14 17:48, schrieb Ticker Berkin:

Hi Thorsten

I can't explain the turn instructions being in the wrong direction for 
some
ranges of angles. What are you seeing this on - Basecamp / MapSource / 
Garmin

Device?


I see this on BaseCamp, Garmin GPSMap 66sr, Garmin Edge 1030+ and 1050.

I have only tested a few junctions with the Garmin devices, the ones in 
the near,

but the result was always identical.

Can you send me the same sections of the log file, the first should 
look like

this:


fixSharpAngles_v4 at 49.478507,10.942814 mask 2 smallestAngle 15.375715 
nArcs 3 nDirectArcs 3 nGroups 3
Arc heading -32.3756 328° angToPrev 166.0431 class 2 speed 2 way 
144732811 isFake false rdDef -2042305213 name null paved true
Arc heading -16.999884 343° angToPrev 15.375715 class 1 speed 2 way 
36138336 isFake false rdDef -485064406 name null paved false
Arc heading 161.5813 162° angToPrev 178.58118 class 1 speed 2 way 
36138336 isFake false rdDef -485064406 name null paved false
Angle 15.375715 between -32.3756 and -16.999884 minAngle 46.0 wantedInc 
30.624285 deltaPred 120.043106 deltaNext 132.58118

decreasing arc with heading 328° by 30.624285
modInitialHeading arc from -32.3756 by -30.624285 to -62.999886
join angle 8.872055 ° at 49.483048,10.932943 increased by 37.127945

If, in this example, way 36138338 has been split, I need to see if 
there is any

way of finding the associated bits of road


But with this build, the "wrong" turn instructions are gone!
This time the 328° heading was used, not the 343°. If you haven't done 
any other changes to your patch except debugging code (I haven't looked 
at the patch yet), then I'm afraid we have somewhere an unstable sort or 
use a hash table, which will not give reproducable results.


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

Re: [mkgmap-dev] Problem in AngleFixer?

[Ticker Berkin]

Hi Thorsten

Apart from moving and adding diagnostics, the only significant change I made was
to remove a test for the arcs on either side of a sharp angle being the same
road, and, if so, not widen the angle. This didn't occur in your example. The
other changes were cosmetic.

With this latest version/build, have all your wrong turn-instructions gone?

Do you use option --preserve-element-order? Elsewhere in the code quite a lot of
effort has been taken to avoid java constructs with unpredictable ordering.

Regards
Ticker

On Thu, 2024-08-15 at 14:24 +0200, Thorsten Kukuk wrote:
> Hi Ticker,
> 
> Am 2024-08-14 17:48, schrieb Ticker Berkin:
> > Hi Thorsten
> > 
> > I can't explain the turn instructions being in the wrong direction for 
> > some
> > ranges of angles. What are you seeing this on - Basecamp / MapSource / 
> > Garmin
> > Device?
> 
> I see this on BaseCamp, Garmin GPSMap 66sr, Garmin Edge 1030+ and 1050.
> 
> I have only tested a few junctions with the Garmin devices, the ones in 
> the near,
> but the result was always identical.
> 
> > Can you send me the same sections of the log file, the first should 
> > look like
> > this:
> 
> fixSharpAngles_v4 at 49.478507,10.942814 mask 2 smallestAngle 15.375715 
> nArcs 3 nDirectArcs 3 nGroups 3
> Arc heading -32.3756 328° angToPrev 166.0431 class 2 speed 2 way 
> 144732811 isFake false rdDef -2042305213 name null paved true
> Arc heading -16.999884 343° angToPrev 15.375715 class 1 speed 2 way 
> 36138336 isFake false rdDef -485064406 name null paved false
> Arc heading 161.5813 162° angToPrev 178.58118 class 1 speed 2 way 
> 36138336 isFake false rdDef -485064406 name null paved false
> Angle 15.375715 between -32.3756 and -16.999884 minAngle 46.0 wantedInc 
> 30.624285 deltaPred 120.043106 deltaNext 132.58118
> decreasing arc with heading 328° by 30.624285
> modInitialHeading arc from -32.3756 by -30.624285 to -62.999886
> join angle 8.872055 ° at 49.483048,10.932943 increased by 37.127945
> 
> > If, in this example, way 36138338 has been split, I need to see if 
> > there is any
> > way of finding the associated bits of road
> 
> But with this build, the "wrong" turn instructions are gone!
> This time the 328° heading was used, not the 343°. If you haven't done 
> any other changes to your patch except debugging code (I haven't looked 
> at the patch yet), then I'm afraid we have somewhere an unstable sort or 
> use a hash table, which will not give reproducable results.
> 
> Regards,
>    Thorsten
> ___
> 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] Problem in AngleFixer?

[Thorsten Kukuk]

Am 2024-08-15 15:49, schrieb Ticker Berkin:

Hi Thorsten

Apart from moving and adding diagnostics, the only significant change I 
made was
to remove a test for the arcs on either side of a sharp angle being the 
same
road, and, if so, not widen the angle. This didn't occur in your 
example. The

other changes were cosmetic.

With this latest version/build, have all your wrong turn-instructions 
gone?


I don't have currently the time to test all examples, but the few I 
tested seems to be Ok now.
Instead of wrong "turn right" for straight forward I have now no message 
for it or "turn left" for the left way.
In some cases I get "keep right" and "keep left" (assumes "Y" junction), 
which is Ok in that cases.


Do you use option --preserve-element-order? Elsewhere in the code quite 
a lot of
effort has been taken to avoid java constructs with unpredictable 
ordering.


No, I'm not using "--preserve-element-order".

Regards,
Thorsten



Regards
Ticker

On Thu, 2024-08-15 at 14:24 +0200, Thorsten Kukuk wrote:

Hi Ticker,

Am 2024-08-14 17:48, schrieb Ticker Berkin:
> Hi Thorsten
>
> I can't explain the turn instructions being in the wrong direction for
> some
> ranges of angles. What are you seeing this on - Basecamp / MapSource /
> Garmin
> Device?

I see this on BaseCamp, Garmin GPSMap 66sr, Garmin Edge 1030+ and 
1050.


I have only tested a few junctions with the Garmin devices, the ones 
in

the near,
but the result was always identical.

> Can you send me the same sections of the log file, the first should
> look like
> this:

fixSharpAngles_v4 at 49.478507,10.942814 mask 2 smallestAngle 
15.375715

nArcs 3 nDirectArcs 3 nGroups 3
Arc heading -32.3756 328° angToPrev 166.0431 class 2 speed 2 way
144732811 isFake false rdDef -2042305213 name null paved true
Arc heading -16.999884 343° angToPrev 15.375715 class 1 speed 2 way
36138336 isFake false rdDef -485064406 name null paved false
Arc heading 161.5813 162° angToPrev 178.58118 class 1 speed 2 way
36138336 isFake false rdDef -485064406 name null paved false
Angle 15.375715 between -32.3756 and -16.999884 minAngle 46.0 
wantedInc

30.624285 deltaPred 120.043106 deltaNext 132.58118
decreasing arc with heading 328° by 30.624285
modInitialHeading arc from -32.3756 by -30.624285 to -62.999886
join angle 8.872055 ° at 49.483048,10.932943 increased by 37.127945

> If, in this example, way 36138338 has been split, I need to see if
> there is any
> way of finding the associated bits of road

But with this build, the "wrong" turn instructions are gone!
This time the 328° heading was used, not the 343°. If you haven't done
any other changes to your patch except debugging code (I haven't 
looked
at the patch yet), then I'm afraid we have somewhere an unstable sort 
or

use a hash table, which will not give reproducable results.

Regards,
   Thorsten
___
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] Problem in AngleFixer?

[Ticker Berkin]

Hi Gerd & Thorsten

This, I hope, is the final version of the changes to AngleFixer.

I've simplified and clarified some of the logic, improved some of the
diagnostics, added more comments and made better choices of when compactDir
format is used. There should be a slight reduction in .img size, fewer time
penalties and better turn-instructions.

Regards
Ticker
Index: src/uk/me/parabola/imgfmt/app/net/AngleChecker.java
===
--- src/uk/me/parabola/imgfmt/app/net/AngleChecker.java	(revision 4921)
+++ src/uk/me/parabola/imgfmt/app/net/AngleChecker.java	(working copy)
@@ -13,7 +13,6 @@
 package uk.me.parabola.imgfmt.app.net;
 
 import java.util.ArrayList;
-import java.util.HashSet;
 import java.util.Iterator;
 import java.util.List;
 import java.util.Map;
@@ -20,6 +19,7 @@
 
 import uk.me.parabola.log.Logger;
 import uk.me.parabola.util.EnhancedProperties;
+import uk.me.parabola.mkgmap.reader.osm.FakeIdGenerator;
 
 /**
  * Find sharp angles at junctions. The Garmin routing algorithm doesn't
@@ -29,15 +29,15 @@
  * mode it is zero, for bicycles it is rather small, for cars it is high.
  * The sharp angles typically don't exist in the real world, they are
  * caused by the simplifications done by mappers.
- * 
- * Maps created for cyclists typically "abuse" the car routing for racing 
+ *
+ * Maps created for cyclists typically "abuse" the car routing for racing
  * bikes, but in this scenario the time penalties are much too high,
  * and detours are likely.
- * 
- * This method tries to modify the initial heading values of the arcs 
+ *
+ * This method tries to modify the initial heading values of the arcs
  * which are used to calculate the angles. Where possible, the values are
- * changed so that angles appear larger. 
- * 
+ * changed so that angles appear larger.
+ *
  * @author Gerd Petermann
  *
  * Somehow these penalties are also applied to "shortest" routing,
@@ -55,6 +55,13 @@
  *
  * Ticker Berkin
  *
+ * This code has two other functions:
+ *
+ * When increasing a sharp angle, try to trigger better turn-instructions by the
+ * choice of which arcs to adjust.
+ *
+ * Use compactDir format (4bits) rather than 8bits for initial heading representaton
+ * when this will give a space saving and not compromise the turn-instructions.
  */
 public class AngleChecker {
 	private static final Logger log = Logger.getLogger(AngleChecker.class);
@@ -68,8 +75,9 @@
 	// If this is >= above, then compactDirs will be used unless other, non-vehicle access angles are sharp
 	private static final float SHARP_DEGREES = COMPACT_DIR_DEGREES;
 	// Experimentation found no benefit in increasing angle beyond 2 "sectors"
-	private static final float MIN_ANGLE = 11.25f; // don't reduce angles to less than this (arbitrary)
-	
+	private static final float MIN_ANGLE = 23f; // don't reduce angles to less than this (1 sector + bit)
+	private static final float STRAIGHT_EPSILON = 3f; // for angle.straightEnough()
+
 	// helper class to collect multiple arcs with (nearly) the same initial headings
 	private class ArcGroup {
 		float initialHeading;
@@ -78,9 +86,8 @@
 		int maxRoadSpeed;
 		int maxRoadClass;
 		byte orAccessMask;
-		HashSet roadDefs = new HashSet<>();
-		
 		List arcs = new ArrayList<>();
+
 		public void addArc(RouteArc arc) {
 			arcs.add(arc);
 			if (arc.getRoadDef().isOneway())
@@ -92,21 +99,42 @@
 			if (arc.getRoadDef().getRoadClass() > maxRoadClass)
 maxRoadClass = arc.getRoadDef().getRoadClass();
 			orAccessMask |= arc.getRoadDef().getAccess();
-			roadDefs.add(arc.getRoadDef());
 		}
 
 		public float getInitialHeading() {
 			return initialHeading;
 		}
-		
+
 		public boolean isOneway() {
+			// ??? ignore for pedestrian only group members
 			return isOneWayTrueCount == arcs.size();
 		}
-		
+
 		public boolean isForward() {
 			return isForwardTrueCount == arcs.size();
 		}
-		
+
+		public boolean sameWay(ArcGroup other) {
+			for (RouteArc thisArc : arcs)
+for (RouteArc otherArc : other.arcs) {
+	// same roadDefs have same wayIds that are unique, so this is OK
+	if (thisArc.getRoadDef() == otherArc.getRoadDef())
+		return true;
+}
+			return false;
+		}
+
+		public boolean sameName(ArcGroup other) {
+			for (RouteArc thisArc : arcs) {
+String thisName = thisArc.getRoadDef().getName();
+if (thisName != null)
+	for (RouteArc otherArc : other.arcs)
+		if (thisName.equals(otherArc.getRoadDef().getName()))
+			return true;
+			}
+			return false;
+		}
+
 		public void modInitialHeading(float modIH) {
 			initialHeading += modIH;
 			if (initialHeading >= 180)
@@ -113,6 +141,7 @@
 initialHeading -= 360;
 			else if (initialHeading < -180)
 initialHeading += 360;
+			log.info("modInitialHeading arc from", arcs.get(0).getInitialHeading(), "by", modIH, "to", initialHeading);
 
 			for (RouteArc arc : arcs) {
 arc.modInitialHeading(modIH);
@@ -123,7 +152,7 @@
 			return arcs.get(0).toString();

Re: [mkgmap-dev] Problem in AngleFixer?

[Gerd Petermann]

Hi Ticker,

the patch solves the original problem at https://www.osm.org/node/27550903
I tried to find other places where the change in the map data produce 
differences in routing but without success so far.
I think that's good news, but all cases only involved footways or tracks so far.

So, I wait for Thorsten to confirm that the patch is an improvement.

Gerd




Von: mkgmap-dev  im Auftrag von Ticker 
Berkin 
Gesendet: Samstag, 24. August 2024 18:30
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Problem in AngleFixer?

Hi Gerd & Thorsten

This, I hope, is the final version of the changes to AngleFixer.

I've simplified and clarified some of the logic, improved some of the
diagnostics, added more comments and made better choices of when compactDir
format is used. There should be a slight reduction in .img size, fewer time
penalties and better turn-instructions.

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

Re: [mkgmap-dev] Problem in AngleFixer?

[Thorsten Kukuk]

Am 2024-08-26 13:55, schrieb Gerd Petermann:

Hi Ticker,

the patch solves the original problem at 
https://www.osm.org/node/27550903
I tried to find other places where the change in the map data produce 
differences in routing but without success so far.
I think that's good news, but all cases only involved footways or 
tracks so far.


So, I wait for Thorsten to confirm that the patch is an improvement.


I did build a map with this patch now and tested all GPX files I created 
for this in BaseCamp. They are all correct.
I will install the map now on my GPS and test it this week on my cycle 
tours.


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

Re: [mkgmap-dev] Problem in AngleFixer?

[Ticker Berkin]

Hi Gerd & Thorsten

I need to test one more scenario where a fast one-way lane splits with equal
priority (eg on a motorway) and check that my changes don't trigger a turn
instruction instead of "keep-left" or "keep-right".

Please don't commit anything until I've tested this.

Ticker

On Mon, 2024-08-26 at 11:55 +, Gerd Petermann wrote:
> Hi Ticker,
> 
> the patch solves the original problem at https://www.osm.org/node/27550903
> I tried to find other places where the change in the map data produce
> differences in routing but without success so far.
> I think that's good news, but all cases only involved footways or tracks so
> far.
> 
> So, I wait for Thorsten to confirm that the patch is an improvement.
> 
> Gerd
> 
> 
> 
> 
> Von: mkgmap-dev  im Auftrag von Ticker
> Berkin 
> Gesendet: Samstag, 24. August 2024 18:30
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Problem in AngleFixer?
> 
> Hi Gerd & Thorsten
> 
> This, I hope, is the final version of the changes to AngleFixer.
> 
> I've simplified and clarified some of the logic, improved some of the
> diagnostics, added more comments and made better choices of when compactDir
> format is used. There should be a slight reduction in .img size, fewer time
> penalties and better turn-instructions.
> 
> Regards
> Ticker
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


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

Re: [mkgmap-dev] Problem in AngleFixer?

[Ticker Berkin]

Hi

I've improved some of the logic where arcs on either side of an angle are one-
way (merging, splitting or continuous).

I didn't detect turn-left/right instructions rather then keep-left/right on the
roads I use where there is a gradual split. However I thought this would be a
possibility in other cases if the angles on the split were increased so it
seemed best give an accurate representation to the device and let it announce
what it considers best.

One-ways merging don't need any increase in angle.

Continuous one-ways were considered to be a flare, eg joining a roundabout or a
more major road and the angle wasn't increased, but there are other cases where
it should be, so I've removed this as a special case.

Patch attached

Ticker

On Mon, 2024-08-26 at 17:16 +0100, Ticker Berkin wrote:
> Hi Gerd & Thorsten
> 
> I need to test one more scenario where a fast one-way lane splits with equal
> priority (eg on a motorway) and check that my changes don't trigger a turn
> instruction instead of "keep-left" or "keep-right".
> 
> Please don't commit anything until I've tested this.
> 
> Ticker
> 
> On Mon, 2024-08-26 at 11:55 +, Gerd Petermann wrote:
> > Hi Ticker,
> > 
> > the patch solves the original problem at https://www.osm.org/node/27550903
> > I tried to find other places where the change in the map data produce
> > differences in routing but without success so far.
> > I think that's good news, but all cases only involved footways or tracks so
> > far.
> > 
> > So, I wait for Thorsten to confirm that the patch is an improvement.
> > 
> > Gerd
> > 
> > 
> > 
> > ________________
> > Von: mkgmap-dev  im Auftrag von
> > Ticker
> > Berkin 
> > Gesendet: Samstag, 24. August 2024 18:30
> > An: Development list for mkgmap
> > Betreff: Re: [mkgmap-dev] Problem in AngleFixer?
> > 
> > Hi Gerd & Thorsten
> > 
> > This, I hope, is the final version of the changes to AngleFixer.
> > 
> > I've simplified and clarified some of the logic, improved some of the
> > diagnostics, added more comments and made better choices of when compactDir
> > format is used. There should be a slight reduction in .img size, fewer time
> > penalties and better turn-instructions.
> > 
> > Regards
> > Ticker
> > ___
> > mkgmap-dev mailing list
> > mkgmap-dev@lists.mkgmap.org.uk
> > https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> 
> 
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Index: src/uk/me/parabola/imgfmt/app/net/AngleChecker.java
===
--- src/uk/me/parabola/imgfmt/app/net/AngleChecker.java	(revision 4921)
+++ src/uk/me/parabola/imgfmt/app/net/AngleChecker.java	(working copy)
@@ -13,7 +13,6 @@
 package uk.me.parabola.imgfmt.app.net;
 
 import java.util.ArrayList;
-import java.util.HashSet;
 import java.util.Iterator;
 import java.util.List;
 import java.util.Map;
@@ -20,6 +19,7 @@
 
 import uk.me.parabola.log.Logger;
 import uk.me.parabola.util.EnhancedProperties;
+import uk.me.parabola.mkgmap.reader.osm.FakeIdGenerator;
 
 /**
  * Find sharp angles at junctions. The Garmin routing algorithm doesn't
@@ -29,15 +29,15 @@
  * mode it is zero, for bicycles it is rather small, for cars it is high.
  * The sharp angles typically don't exist in the real world, they are
  * caused by the simplifications done by mappers.
- * 
- * Maps created for cyclists typically "abuse" the car routing for racing 
+ *
+ * Maps created for cyclists typically "abuse" the car routing for racing
  * bikes, but in this scenario the time penalties are much too high,
  * and detours are likely.
- * 
- * This method tries to modify the initial heading values of the arcs 
+ *
+ * This method tries to modify the initial heading values of the arcs
  * which are used to calculate the angles. Where possible, the values are
- * changed so that angles appear larger. 
- * 
+ * changed so that angles appear larger.
+ *
  * @author Gerd Petermann
  *
  * Somehow these penalties are also applied to "shortest" routing,
@@ -55,6 +55,13 @@
  *
  * Ticker Berkin
  *
+ * This code has two other functions:
+ *
+ * When increasing a sharp angle, try to trigger better turn-instructions by the
+ * choice of which arcs to adjust.
+ *
+ * Use compactDir format (4bits) rather than 8bits for initial heading representaton
+ * when this will give a space saving and not compromise the turn-instructions.
  */
 public class AngleChecker

Re: [mkgmap-dev] Problem in AngleFixer?

[Thorsten Kukuk]

Hi,

I tested that patch in BaseCamp and yesterday evening on a bicycle tour. 
Navigation instructions were good, I haven't seen any wrong hint, no 
missing one and also no superfluous. Same result as I had already on 
several other tours the last days with v5.

Great job, that patch is a big improvement!

With v6 I had some wired navigation instructions on one place when when 
I deviated from the route and it automatically guided me back. But when 
I did inspect the map today, there is a small, parallel path, could be 
very well that the Garmin device wanted to route me via that way and it 
was not visible on the small display.
I couldn't reproduce that with a GPX track or BaseCamp. Need to check 
the OSM data later, I assume wrong tags.
Or I need to switch the line types in my maps. It's really wired which 
effect line types have on routing and navigation instructions.
So if you get flooded with useless navigation instructions, this could 
also be the fault of using the wrong line type in your map...


Thorsten

Am 2024-08-29 10:42, schrieb Ticker Berkin:

Hi

I've improved some of the logic where arcs on either side of an angle 
are one-

way (merging, splitting or continuous).

I didn't detect turn-left/right instructions rather then 
keep-left/right on the
roads I use where there is a gradual split. However I thought this 
would be a
possibility in other cases if the angles on the split were increased so 
it
seemed best give an accurate representation to the device and let it 
announce

what it considers best.

One-ways merging don't need any increase in angle.

Continuous one-ways were considered to be a flare, eg joining a 
roundabout or a
more major road and the angle wasn't increased, but there are other 
cases where

it should be, so I've removed this as a special case.

Patch attached

Ticker

On Mon, 2024-08-26 at 17:16 +0100, Ticker Berkin wrote:

Hi Gerd & Thorsten

I need to test one more scenario where a fast one-way lane splits with 
equal
priority (eg on a motorway) and check that my changes don't trigger a 
turn

instruction instead of "keep-left" or "keep-right".

Please don't commit anything until I've tested this.

Ticker

On Mon, 2024-08-26 at 11:55 +, Gerd Petermann wrote:
> Hi Ticker,
>
> the patch solves the original problem at https://www.osm.org/node/27550903
> I tried to find other places where the change in the map data produce
> differences in routing but without success so far.
> I think that's good news, but all cases only involved footways or tracks so
> far.
>
> So, I wait for Thorsten to confirm that the patch is an improvement.
>
> Gerd
>
>
>
> 
> Von: mkgmap-dev  im Auftrag von
> Ticker
> Berkin 
> Gesendet: Samstag, 24. August 2024 18:30
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Problem in AngleFixer?
>
> Hi Gerd & Thorsten
>
> This, I hope, is the final version of the changes to AngleFixer.
>
> I've simplified and clarified some of the logic, improved some of the
> diagnostics, added more comments and made better choices of when compactDir
> format is used. There should be a slight reduction in .img size, fewer time
> penalties and better turn-instructions.
>
> Regards
> Ticker
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
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] Problem in AngleFixer?

[Ticker Berkin]

Hi Thorsten

Thanks for testing this.

The routable line types are:
  0x01 ... 0x13  highways
  0x16   highway
  0x1a ... 0x1b  ferry
on newer garmin devices/Basecamp
  0x2c ... 0x2f  ?/Climbing path/Via Ferrata/Cable Car

Using these for non-routables can break routing nearby in some Garmin software;
I've certainly seen this behaviour in Basecamp. The default style uses the
correct routable/non-routable types for the context.

I've seen suggestions that 0x17 is routable. This is used by the default style
as non-routable. 

Routable types 0x08, 0x09, 0x0c, 0x1a and 0x1b and maybe 0x13 have slightly
different behaviour - mainly relating to the navigation instructions issued.

Regards
Ticker

On Fri, 2024-08-30 at 09:59 +0200, Thorsten Kukuk wrote:
> 
> Hi,
> 
> I tested that patch in BaseCamp and yesterday evening on a bicycle tour. 
> Navigation instructions were good, I haven't seen any wrong hint, no 
> missing one and also no superfluous. Same result as I had already on 
> several other tours the last days with v5.
> Great job, that patch is a big improvement!
> 
> With v6 I had some wired navigation instructions on one place when when 
> I deviated from the route and it automatically guided me back. But when 
> I did inspect the map today, there is a small, parallel path, could be 
> very well that the Garmin device wanted to route me via that way and it 
> was not visible on the small display.
> I couldn't reproduce that with a GPX track or BaseCamp. Need to check 
> the OSM data later, I assume wrong tags.
> Or I need to switch the line types in my maps. It's really wired which 
> effect line types have on routing and navigation instructions.
> So if you get flooded with useless navigation instructions, this could 
> also be the fault of using the wrong line type in your map...
> 
> Thorsten

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

Re: [mkgmap-dev] Problem in AngleFixer?

[Thorsten Kukuk]

Hi Ticker,

thanks, but the problem is not routable vs. non-routable, but that the 
device seems to prefer to leave the cycleway for a longer footway 
instead of staying on the shorter cycleway, which should additional have 
a higher road_speed and a higher road_class.
And that it does not work here means either the tags on the ways are not 
correct or there is an error in my style.

Something to debug for the next rainy day :)

Thorsten


Am 2024-08-30 17:21, schrieb Ticker Berkin:

Hi Thorsten

Thanks for testing this.

The routable line types are:
  0x01 ... 0x13  highways
  0x16   highway
  0x1a ... 0x1b  ferry
on newer garmin devices/Basecamp
  0x2c ... 0x2f  ?/Climbing path/Via Ferrata/Cable Car

Using these for non-routables can break routing nearby in some Garmin 
software;
I've certainly seen this behaviour in Basecamp. The default style uses 
the

correct routable/non-routable types for the context.

I've seen suggestions that 0x17 is routable. This is used by the 
default style

as non-routable.

Routable types 0x08, 0x09, 0x0c, 0x1a and 0x1b and maybe 0x13 have 
slightly
different behaviour - mainly relating to the navigation instructions 
issued.


Regards
Ticker

On Fri, 2024-08-30 at 09:59 +0200, Thorsten Kukuk wrote:


Hi,

I tested that patch in BaseCamp and yesterday evening on a bicycle 
tour.

Navigation instructions were good, I haven't seen any wrong hint, no
missing one and also no superfluous. Same result as I had already on
several other tours the last days with v5.
Great job, that patch is a big improvement!

With v6 I had some wired navigation instructions on one place when 
when
I deviated from the route and it automatically guided me back. But 
when

I did inspect the map today, there is a small, parallel path, could be
very well that the Garmin device wanted to route me via that way and 
it

was not visible on the small display.
I couldn't reproduce that with a GPX track or BaseCamp. Need to check
the OSM data later, I assume wrong tags.
Or I need to switch the line types in my maps. It's really wired which
effect line types have on routing and navigation instructions.
So if you get flooded with useless navigation instructions, this could
also be the fault of using the wrong line type in your map...

Thorsten


___
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] problem with style

[Henning Scholland]

Hi,
I found the error: It must be level 1-6. The question is: Is the wiki 
wrong when saying - (also explaining this in 
text) or is it a bug/change in mkgmap?


http://wiki.openstreetmap.org/wiki/Mkgmap/help/style_rules#level_.28see_also_resolution.29

Henning

Am 20.05.2013 16:06, schrieb Henning Scholland:

Hi,
does someone has an explanation, why the second line isn't rendered in 
the map? Only results of line 1 and 3 are visiblewith overview2 
r2616(haven't tried other versions).


Henning

highway=trunk& area!=yes & access=no { set name='${name} (${ref})' | 
'${ref}' | '${name}'} [0x10003 level 6 continue]
highway=trunk & area!=yes & access!=no { set name='${name} (${ref})' | 
'${ref}' | '${name}'} [0x10003 level 6-1 continue]
highway=trunk & area!=yes & access!=no { set name='${name} (${ref})' | 
'${ref}' | '${name}'} [0x03 road_class=1 road_speed=1 level 0 continue]




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


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

Re: [mkgmap-dev] problem with style

[Steve Ratcliffe]

On 20/05/13 17:14, Henning Scholland wrote:
> I found the error: It must be level 1-6. The question is: Is the wiki
> wrong when saying - (also explaining this in
> text) or is it a bug/change in mkgmap?

The wiki is wrong to say that the higher number must be first (it was
documenting a bug), although I thought that I had fixed it so that you
could have them either way around.

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

Re: [mkgmap-dev] problem with style

[GerdP]

Hi,

I found this comment in the code:
// Previously there was a bug where the order 
was reversed, so we swap
the numbers if they are
// the wrong way round.
// This is not done for level as that never had 
the bug.

Don't know why it happens now with the overview map, but I think 
it should do no harm to swap the values as well.
This is implemented in r2622.

Gerd


Steve Ratcliffe wrote
> On 20/05/13 17:14, Henning Scholland wrote:
>> I found the error: It must be level 1-6. The question is: Is the wiki
>> wrong when saying 
> 
> -
> 
>  (also explaining this in
>> text) or is it a bug/change in mkgmap?
> 
> The wiki is wrong to say that the higher number must be first (it was
> documenting a bug), although I thought that I had fixed it so that you
> could have them either way around.
> 
> ..Steve
> ___
> mkgmap-dev mailing list

> mkgmap-dev@.org

> http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev





--
View this message in context: 
http://gis.19327.n5.nabble.com/problem-with-style-tp5761886p5762831.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] Problem posting to list

[Steve Ratcliffe]

Hi

There has been a short problem posting to the list - my fault, I broke
it.

If you see this then all is well again.

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

[mkgmap-dev] Problem with turn restriction

[WanMil]

Hi,

attached test file shows a problem with turn restrictions defined on 
very short streets that are removed by mkgmap.


When routing from the parking space in the west to the parking space in 
the north the route should go over the oneway in the south. But because 
the turn restriction at the end of street 1 has a very short to-way the 
turn restriction is removed by mkgmap.


@Gerd: do you see any chance to fix that so that the turn restriction is 
not removed? (I have not tested the high precision branch).


WanMil


  


  
  
  


  
  
  
  
  
  
  
  
  





  
  




  
  









  
  





  
  



  
  





  

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

[mkgmap-dev] Problem with this restriction?

[Bernd Weigelt]

Hi

I got this error if i build a map around DE-Starnberg

Time started: Thu Apr 24 20:50:22 CEST 2014
java.lang.AssertionError
at 
uk.me.parabola.imgfmt.app.net.RouteRestriction.(RouteRestriction.java:88)
at 
uk.me.parabola.imgfmt.app.net.RoadNetwork.addRestriction(RoadNetwork.java:536)
at 
uk.me.parabola.mkgmap.general.MapDetails.addRestriction(MapDetails.java:131)
at 
uk.me.parabola.mkgmap.reader.osm.RestrictionRelation.addRestriction(RestrictionRelation.java:535)
at 
uk.me.parabola.mkgmap.osmstyle.StyledConverter.end(StyledConverter.java:495)
at 
uk.me.parabola.mkgmap.reader.osm.ElementSaver.convert(ElementSaver.java:248)
at 
uk.me.parabola.mkgmap.reader.osm.o5m.O5mBinMapDataSource.load(O5mBinMapDataSource.java:53)
at 
uk.me.parabola.mkgmap.reader.osm.OsmMapDataSource.load(OsmMapDataSource.java:127)
at uk.me.parabola.mkgmap.main.MapMaker.loadFromFile(MapMaker.java:167)
at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:63)
at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:220)
at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:216)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)
Time finished: Thu Apr 24 20:50:54 CEST 2014
Total time taken: 31241ms


last entry in mkgmap.log.0
2014/04/24 20:50:53 Warnung (RoadNetwork): 
/home/bernd/map_build/tiles/65020018.o5m: Turn restriction (no_u_turn) 
http://www.openstreetmap.org/browse/relation/2254003 (at 
http://www.openstreetmap.org/?mlat=48.119082&mlon=11.583557&zoom=17) the angle 
of the from and to way don't match the restriction

http://www.openstreetmap.org/relation/2254003

link to mapdata
http://files.mkgmap.org.uk/download/204/65020018.o5m

Bernd

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

[mkgmap-dev] Problem with splitter r393

[Bernd Weigelt]

Hi

FYI:

splitter r393 dies with following error, if i try to split my DACH-extract,
all other extracts are not affected

java.lang.ArrayIndexOutOfBoundsException: -184650
at 
uk.me.parabola.splitter.O5mMapParser.setStringRefPair(O5mMapParser.java:355)
at 
uk.me.parabola.splitter.O5mMapParser.readAuthor(O5mMapParser.java:408)
at 
uk.me.parabola.splitter.O5mMapParser.readVersionTsAuthor(O5mMapParser.java:372)
at 
uk.me.parabola.splitter.O5mMapParser.readNode(O5mMapParser.java:251)
at 
uk.me.parabola.splitter.O5mMapParser.readFile(O5mMapParser.java:187)
at uk.me.parabola.splitter.O5mMapParser.parse(O5mMapParser.java:133)
at uk.me.parabola.splitter.Main.processOSMFiles(Main.java:1362)
at uk.me.parabola.splitter.Main.processMap(Main.java:874)
at uk.me.parabola.splitter.Main.genProblemLists(Main.java:697)
at 
uk.me.parabola.splitter.Main.partitionAreasForProblemListGenerator(Main.java:729)
at uk.me.parabola.splitter.Main.split(Main.java:307)
at uk.me.parabola.splitter.Main.start(Main.java:181)
at uk.me.parabola.splitter.Main.main(Main.java:151)



here are the log files
http://files.mkgmap.org.uk/download/210/20140526_0900.zip

Bernd


-- 
amarok2 now playing:




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

[mkgmap-dev] Problem in splitter (Africa)

[Gerd Petermann]

Hi all,

I wonder what splitter should do in this case:

Stephen uses paramter --max-nodes=8 
and splitter reports 
"Highest node count in a single grid element is 557,084"

It is obvious that at least one tile will have much more than the requested 
80.000 nodes,
on the other hand, the file africa.osm.pbf contains large nearly empty areas,
and that makes it very difficult to find a good split.
The current version r416 fails because it doesn't accept tiles with less than 
5% of 
the max-nodes value, so it searches for a solution where every tile has at 
least 4000 nodes,
and that might not exist.

I see these options:
1) splitter can continue trying to split the data, accepting almost empty 
output files
(e.g. some with < 5 nodes and very high aspect ratios like 32)
2) if that fails,  splitter can set the max-nodes value to 557,084 and try again
3) or stop with an error message that tells the user that it is not possible
to split with the used resolution
4) or restart using a higher resolution  (15 would be required here instead of 
13),

@Stephen
What reason do you have to use such a small max-nodes value? 
Would it be ok for you to use a higher one?

Gerd




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

Re: [mkgmap-dev] problem in mkgmap

[Gerd Petermann]

Hi all,

this problem seems to be caused by way 
http://www.openstreetmap.org/way/141294301

I can reproduce it with the default style and will try to fix it.

Gerd

Date: Tue, 9 Jun 2015 14:50:52 +1000
From: steve.sgalow...@gmail.com
To: mkgmap-dev@lists.mkgmap.org.uk
Subject: [mkgmap-dev] problem in mkgmap

1 africa needs admin  level 5 bu unshure which state triggered this 
then have a prob wher a bbox is not spli only found on compile 

stephen 


___
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] problem with mkgmap

[Gerd Petermann]

Hello,


the message java.lang.NoClassDefFoundError means that your package

is probably incomplete. I assume that you have move splitter.jar to a different

directory without also copying the lib diroctory.

If that doesn't help, please download and unzip

http://www.mkgmap.org.uk/download/splitter-r427.zip


You should be able to execute the command in the directory

with splitter.jar


ciao,

Gerd




Von: mkgmap-dev-boun...@lists.mkgmap.org.uk 
 im Auftrag von A Guertin 

Gesendet: Donnerstag, 5. November 2015 03:23
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: [mkgmap-dev] problem with mkgmap

Hello,

What can I do with this problem? Unable to split

See attachement

Andre
--

[cid:part1.05080104.02060103@videotron.ca]





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

Re: [mkgmap-dev] problem with mkgmap

[Steve Sgalowski]

i can try this on a windows and it will work fine

Stephen


On Thu, Nov 5, 2015 at 12:23 PM, A Guertin  wrote:

> Hello,
>
> What can I do with this problem? Unable to split
>
> See attachement
>
> Andre
> --
>
>
>
>
>
>
>
>
> ___
> 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] problem with mkgmap

[A Guertin]

Hello

I would like to thank you for your support. Working now. I made some 
mistakes with my repositeries.


André
--







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

Re: [mkgmap-dev] Problem with r3706

[Gerd Petermann]

Hi Arndt,

not sure, but this sounds like an I/O problem. Please rerun mkgmap r3706
with 
an empty directory (no old *.img files). Does that help?

The probem in 3702 was fixed with r3704, your new problem is probably not
related to this.

Gerd 


Arndt Röhrig wrote
> 
> 
> 
> Hello everybody, i use mkgmap r3706. It run 2 times. The first one makes
> the img-files. The second one makes the mdr/mdrx files. The first step
> works fine, without error-messages, but the second step produces an error
> message and crashes: "Exception in thread "main"
> java.lang.AssertionError: Invalid label offset found 1315595
>     at
> uk.me.parabola.imgfmt.app.lbl.LBLFileReader.fetchLabel(LBLFileReader.
> java:87)     at
> uk.me.parabola.imgfmt.app.trergn.RGNFileReader.fetchPointsCommon(RGNF
> ileReader.java:123)     at
> uk.me.parabola.imgfmt.app.trergn.RGNFileReader.pointsForSubdiv(RGNFil
> eReader.java:84)     at
> uk.me.parabola.imgfmt.app.map.MapReader.pointsForLevel(MapReader.java
> :119)     at
> uk.me.parabola.mkgmap.combiners.MdrBuilder.addPoints(MdrBuilder.java: 273)
>     at
> uk.me.parabola.mkgmap.combiners.MdrBuilder.onMapEnd(MdrBuilder.java:1 78)
>     at
> uk.me.parabola.mkgmap.main.Main.endOptions(Main.java:600)
>     at
> uk.me.parabola.mkgmap.CommandArgsReader.readArgs(CommandArgsReader.ja
> va:128)     at
> uk.me.parabola.mkgmap.main.Main.mainStart(Main.java:135)
>     at
> uk.me.parabola.mkgmap.main.Main.main(Main.java:106)"   
>               
>          When i use mkgmap 3702 an error
> message at the first step appears, the second step works fine:
> "SCHWERWIEGEND (ShapeMergeFilter): ..\Splitter\8804.osm.pbf:
> ignoring shape w ith id 364926659 and type 0x13 at resolution 24, it has 4
> points and has an empt y area" The OSM-Data is
> "nordrhein-westfalen.osm.pbf". An other map "Kanaran"
> works fine, without error. Whats the reason for this and what can i do?
> Best regards Arndt 
> 
> ___
> mkgmap-dev mailing list

> mkgmap-dev@.org

> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev





--
View this message in context: 
http://gis.19327.n8.nabble.com/Problem-with-r3706-tp5886790p5886791.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Problem with r3706

[Gerd Petermann]

I've got some more test data from Arndt, I've reproduced the assertion, here
is the test data:
http://files.mkgmap.org.uk/download/316/test.zip

The problem seems to be caused by the new 
--order-by-decreasing-area option, if I remove that from the options file
the problem is gone.

@Ticker: Do you have time to analyse it? I assume the problem is that we set
a flag like "extended type points exist" and later remove the corresponding
data. Does that ring a bell?

Gerd

Arndt Röhrig wrote
> 
> 
> 
> Hello everybody, i use mkgmap r3706. It run 2 times. The first one makes
> the img-files. The second one makes the mdr/mdrx files. The first step
> works fine, without error-messages, but the second step produces an error
> message and crashes: "Exception in thread "main"
> java.lang.AssertionError: Invalid label offset found 1315595
>     at
> uk.me.parabola.imgfmt.app.lbl.LBLFileReader.fetchLabel(LBLFileReader.
> java:87)     at
> uk.me.parabola.imgfmt.app.trergn.RGNFileReader.fetchPointsCommon(RGNF
> ileReader.java:123)     at
> uk.me.parabola.imgfmt.app.trergn.RGNFileReader.pointsForSubdiv(RGNFil
> eReader.java:84)     at
> uk.me.parabola.imgfmt.app.map.MapReader.pointsForLevel(MapReader.java
> :119)     at
> uk.me.parabola.mkgmap.combiners.MdrBuilder.addPoints(MdrBuilder.java: 273)
>     at
> uk.me.parabola.mkgmap.combiners.MdrBuilder.onMapEnd(MdrBuilder.java:1 78)
>     at
> uk.me.parabola.mkgmap.main.Main.endOptions(Main.java:600)
>     at
> uk.me.parabola.mkgmap.CommandArgsReader.readArgs(CommandArgsReader.ja
> va:128)     at
> uk.me.parabola.mkgmap.main.Main.mainStart(Main.java:135)
>     at
> uk.me.parabola.mkgmap.main.Main.main(Main.java:106)"   
>               
>          When i use mkgmap 3702 an error
> message at the first step appears, the second step works fine:
> "SCHWERWIEGEND (ShapeMergeFilter): ..\Splitter\8804.osm.pbf:
> ignoring shape w ith id 364926659 and type 0x13 at resolution 24, it has 4
> points and has an empt y area" The OSM-Data is
> "nordrhein-westfalen.osm.pbf". An other map "Kanaran"
> works fine, without error. Whats the reason for this and what can i do?
> Best regards Arndt 
> 
> ___
> mkgmap-dev mailing list

> mkgmap-dev@.org

> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev





--
View this message in context: 
http://gis.19327.n8.nabble.com/Problem-with-r3706-tp5886790p5886799.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Problem with r3706

[Ticker Berkin]

I'll have a look. I didn't intentionally change extended type
behaviour, but shapes will end up in different subdivisions with the
option applied

Ticker


On Fri, 2016-12-02 at 07:09 -0700, Gerd Petermann wrote:
> I've got some more test data from Arndt, I've reproduced the
> assertion, here
> is the test data:
> http://files.mkgmap.org.uk/download/316/test.zip
> 
> The problem seems to be caused by the new 
> --order-by-decreasing-area option, if I remove that from the options
> file
> the problem is gone.
> 
> @Ticker: Do you have time to analyse it? I assume the problem is that
> we set
> a flag like "extended type points exist" and later remove the
> corresponding
> data. Does that ring a bell?
> 
> Gerd
> 
> Arndt Röhrig wrote
> > 
> > 
> > 
> > Hello everybody, i use mkgmap r3706. It run 2 times. The first one
> > makes
> > the img-files. The second one makes the mdr/mdrx files. The first
> > step
> > works fine, without error-messages, but the second step produces an
> > error
> > message and crashes: "Exception in thread "main"
> > java.lang.AssertionError: Invalid label offset found 1315595
> >     at
> > uk.me.parabola.imgfmt.app.lbl.LBLFileReader.fetchLabel(LBLFileReade
> > r.
> > java:87)     at
> > uk.me.parabola.imgfmt.app.trergn.RGNFileReader.fetchPointsCommon(RG
> > NF
> > ileReader.java:123)     at
> > uk.me.parabola.imgfmt.app.trergn.RGNFileReader.pointsForSubdiv(RGNF
> > il
> > eReader.java:84)     at
> > uk.me.parabola.imgfmt.app.map.MapReader.pointsForLevel(MapReader.ja
> > va
> > :119)     at
> > uk.me.parabola.mkgmap.combiners.MdrBuilder.addPoints(MdrBuilder.jav
> > a: 273)
> >     at
> > uk.me.parabola.mkgmap.combiners.MdrBuilder.onMapEnd(MdrBuilder.java
> > :1 78)
> >     at
> > uk.me.parabola.mkgmap.main.Main.endOptions(Main.java:600)
> >     at
> > uk.me.parabola.mkgmap.CommandArgsReader.readArgs(CommandArgsReader.
> > ja
> > va:128)     at
> > uk.me.parabola.mkgmap.main.Main.mainStart(Main.java:135)
> >     at
> > uk.me.parabola.mkgmap.main.Main.main(Main.java:106)"
> >   
> >               
> >          When i use mkgmap 3702 an
> > error
> > message at the first step appears, the second step works fine:
> > "SCHWERWIEGEND (ShapeMergeFilter):
> > ..\Splitter\8804.osm.pbf:
> > ignoring shape w ith id 364926659 and type 0x13 at resolution 24,
> > it has 4
> > points and has an empt y area" The OSM-Data is
> > "nordrhein-westfalen.osm.pbf". An other map
> > "Kanaran"
> > works fine, without error. Whats the reason for this and what can i
> > do?
> > Best regards Arndt 
> > 
> > ___
> > mkgmap-dev mailing list
> 
> > mkgmap-dev@.org
> 
> > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> 
> 
> 
> 
> 
> --
> View this message in context: http://gis.19327.n8.nabble.com/Problem-
> with-r3706-tp5886790p5886799.html
> Sent from the Mkgmap Development mailing list archive at Nabble.com.
> ___
> 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] Problem with r3706

[Arndt Röhrig]

Hi,Thank you all for the support!Best regaardsTicker Berkin  hat am 2. Dezember 2016 um 15:22 geschrieben:I'll have a look. I didn't intentionally change extended typebehaviour, but shapes will end up in different subdivisions with theoption appliedTickerOn Fri, 2016-12-02 at 07:09 -0700, Gerd Petermann wrote:I've got some more test data from Arndt, I've reproduced theassertion, hereis the test data:http://files.mkgmap.org.uk/download/316/test.zipThe problem seems to be caused by the new --order-by-decreasing-area option, if I remove that from the optionsfilethe problem is gone.@Ticker: Do you have time to analyse it? I assume the problem is thatwe seta flag like "extended type points exist" and later remove thecorrespondingdata. Does that ring a bell?GerdArndt Röhrig wrote Hello everybody, i use mkgmap r3706. It run 2 times. The first onemakesthe img-files. The second one makes the mdr/mdrx files. The firststepworks fine, without error-messages, but the second step produces anerrormessage and crashes: "Exception in thread "main"java.lang.AssertionError: Invalid label offset found 1315595    atuk.me.parabola.imgfmt.app.lbl.LBLFileReader.fetchLabel(LBLFileReader.java:87)     atuk.me.parabola.imgfmt.app.trergn.RGNFileReader.fetchPointsCommon(RGNFileReader.java:123)     atuk.me.parabola.imgfmt.app.trergn.RGNFileReader.pointsForSubdiv(RGNFileReader.java:84)     atuk.me.parabola.imgfmt.app.map.MapReader.pointsForLevel(MapReader.java:119)     atuk.me.parabola.mkgmap.combiners.MdrBuilder.addPoints(MdrBuilder.java: 273)    atuk.me.parabola.mkgmap.combiners.MdrBuilder.onMapEnd(MdrBuilder.java:1 78)    atuk.me.parabola.mkgmap.main.Main.endOptions(Main.java:600)    atuk.me.parabola.mkgmap.CommandArgsReader.readArgs(CommandArgsReader.java:128)     atuk.me.parabola.mkgmap.main.Main.mainStart(Main.java:135)    atuk.me.parabola.mkgmap.main.Main.main(Main.java:106)"                     When i use mkgmap 3702 anerrormessage at the first step appears, the second step works fine:"SCHWERWIEGEND (ShapeMergeFilter):..\Splitter\8804.osm.pbf:ignoring shape w ith id 364926659 and type 0x13 at resolution 24,it has 4points and has an empt y area" The OSM-Data is"nordrhein-westfalen.osm.pbf". An other map"Kanaran"works fine, without error. Whats the reason for this and what can ido?Best regards Arndt ___mkgmap-dev mailing listmkgmap-dev@.orghttp://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev--View this message in context: http://gis.19327.n8.nabble.com/Problem-with-r3706-tp5886790p5886799.htmlSent from the Mkgmap Development mailing list archive at Nabble.com.___mkgmap-dev mailing listmkgmap-dev@lists.mkgmap.org.ukhttp://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev___mkgmap-dev mailing listmkgmap-dev@lists.mkgmap.org.ukhttp://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

Re: [mkgmap-dev] Problem with r3706

[Ticker Berkin]

Hi Gerd

I've been tearing my hair out over this one.

With the test data supplied, the SubDivision structure in the main
output .img file is incorrect. Just changing how areas are split (ie
relaxing the constraint that bounds are exactly representable at the
zoom/shift level) stops the crash, so this is what I've done in the
attached patch.

Sometime soon I'll try and work out when/where it goes wrong but I've
been looking in so many places, thinking I'd tracked down the problem,
only to find no difference, that I want to give up for a while.

Best wishes
Ticker


On Fri, 2016-12-02 at 15:49 +0100, Arndt Röhrig wrote:
> Hi,
> Thank you all for the support!
> 
> Best regaards
> 
> Ticker Berkin  hat am 2. Dezember 2016 um
> 15:22 geschrieben:
> 
> 
> I'll have a look. I didn't intentionally change extended type
> behaviour, but shapes will end up in different subdivisions with the
> option applied
> 
> Ticker
> 
> 
> On Fri, 2016-12-02 at 07:09 -0700, Gerd Petermann wrote:
> I've got some more test data from Arndt, I've reproduced the
> assertion, here
> is the test data:
> http://files.mkgmap.org.uk/download/316/test.zip
> 
> The problem seems to be caused by the new 
> --order-by-decreasing-area option, if I remove that from the options
> file
> the problem is gone.
> 
> @Ticker: Do you have time to analyse it? I assume the problem is that
> we set
> a flag like "extended type points exist" and later remove the
> corresponding
> data. Does that ring a bell?
> 
> Gerd
> 
> Arndt Röhrig wrote
> 
> 
> 
> Hello everybody, i use mkgmap r3706. It run 2 times. The first one
> makes
> the img-files. The second one makes the mdr/mdrx files. The first
> step
> works fine, without error-messages, but the second step produces an
> error
> message and crashes: "Exception in thread "main"
> java.lang.AssertionError: Invalid label offset found 1315595
>     at
> uk.me.parabola.imgfmt.app.lbl.LBLFileReader.fetchLabel(LBLFileReade
> r.
> java:87)     at
> uk.me.parabola.imgfmt.app.trergn.RGNFileReader.fetchPointsCommon(RG
> NF
> ileReader.java:123)     at
> uk.me.parabola.imgfmt.app.trergn.RGNFileReader.pointsForSubdiv(RGNF
> il
> eReader.java:84)     at
> uk.me.parabola.imgfmt.app.map.MapReader.pointsForLevel(MapReader.ja
> va
> :119)     at
> uk.me.parabola.mkgmap.combiners.MdrBuilder.addPoints(MdrBuilder.jav
> a: 273)
>     at
> uk.me.parabola.mkgmap.combiners.MdrBuilder.onMapEnd(MdrBuilder.java
> :1 78)
>     at
> uk.me.parabola.mkgmap.main.Main.endOptions(Main.java:600)
>     at
> uk.me.parabola.mkgmap.CommandArgsReader.readArgs(CommandArgsReader.
> ja
> va:128)     at
> uk.me.parabola.mkgmap.main.Main.mainStart(Main.java:135)
>     at
> uk.me.parabola.mkgmap.main.Main.main(Main.java:106)"
>   
>               
>          When i use mkgmap 3702 an
> error
> message at the first step appears, the second step works fine:
> "SCHWERWIEGEND (ShapeMergeFilter):
> ..\Splitter\8804.osm.pbf:
> ignoring shape w ith id 364926659 and type 0x13 at resolution 24,
> it has 4
> points and has an empt y area" The OSM-Data is
> "nordrhein-westfalen.osm.pbf". An other map
> "Kanaran"
> works fine, without error. Whats the reason for this and what can i
> do?
> Best regards Arndt 
> 
> ___
> mkgmap-dev mailing list
> mkgmap-dev@.org
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> 
> 
> 
> 
> --
> View this message in context: http://gis.19327.n8.nabble.com/Problem-
> with-r3706-tp5886790p5886799.html
> Sent from the Mkgmap Development mailing list archive at Nabble.com.
> ___
> 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
> > 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-devIndex: src/uk/me/parabola/mkgmap/build/MapArea.java
===
--- src/uk/me/parabola/mkgmap/build/MapArea.java	(revision 3716)
+++ src/uk/me/parabola/mkgmap/build/MapArea.java	(working copy)
@@ -204,7 +204,23 @@
 	 * @return An array of the new MapArea's or null if can't split.
 	 */
 	public MapArea[] split(int nx, int ny, int resolution, Area bounds, boolean orderByDecreasingArea) {
+/*
 		int resolutionShift = orderByDecreasingArea ? (24 - resolution) : 0;
+Sometimes getting a corrupt subDivision section in the generated map when align to the zoom level
+(or the linkage has gone wrong). Reading back the map to make an index crashes because logic that
+traverses the SubDivisions to gather [Ind]Points tries to interpret some arbitary data as a SubDivision.
+
+The Su

Re: [mkgmap-dev] Problem with r3706

[Gerd Petermann]

Hi Ticker,


thanks, I'll have a look later.  Maybe it is related to one of my recent 
changes where

I changed some of those constraints.


Gerd


Von: mkgmap-dev  im Auftrag von Ticker 
Berkin 
Gesendet: Mittwoch, 7. Dezember 2016 16:08:22
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] Problem with r3706

Hi Gerd

I've been tearing my hair out over this one.

With the test data supplied, the SubDivision structure in the main
output .img file is incorrect. Just changing how areas are split (ie
relaxing the constraint that bounds are exactly representable at the
zoom/shift level) stops the crash, so this is what I've done in the
attached patch.

Sometime soon I'll try and work out when/where it goes wrong but I've
been looking in so many places, thinking I'd tracked down the problem,
only to find no difference, that I want to give up for a while.

Best wishes
Ticker


On Fri, 2016-12-02 at 15:49 +0100, Arndt Röhrig wrote:
> Hi,
> Thank you all for the support!
>
> Best regaards
>
> Ticker Berkin  hat am 2. Dezember 2016 um
> 15:22 geschrieben:
>
>
> I'll have a look. I didn't intentionally change extended type
> behaviour, but shapes will end up in different subdivisions with the
> option applied
>
> Ticker
>
>
> On Fri, 2016-12-02 at 07:09 -0700, Gerd Petermann wrote:
> I've got some more test data from Arndt, I've reproduced the
> assertion, here
> is the test data:
> http://files.mkgmap.org.uk/download/316/test.zip
>
> The problem seems to be caused by the new
> --order-by-decreasing-area option, if I remove that from the options
> file
> the problem is gone.
>
> @Ticker: Do you have time to analyse it? I assume the problem is that
> we set
> a flag like "extended type points exist" and later remove the
> corresponding
> data. Does that ring a bell?
>
> Gerd
>
> Arndt Röhrig wrote
> <!DOCTYPE html>
>
>
> Hello everybody, i use mkgmap r3706. It run 2 times. The first one
> makes
> the img-files. The second one makes the mdr/mdrx files. The first
> step
> works fine, without error-messages, but the second step produces an
> error
> message and crashes: "Exception in thread "main"
> java.lang.AssertionError: Invalid label offset found 1315595
>     at
> uk.me.parabola.imgfmt.app.lbl.LBLFileReader.fetchLabel(LBLFileReade
> r.
> java:87)     at
> uk.me.parabola.imgfmt.app.trergn.RGNFileReader.fetchPointsCommon(RG
> NF
> ileReader.java:123)     at
> uk.me.parabola.imgfmt.app.trergn.RGNFileReader.pointsForSubdiv(RGNF
> il
> eReader.java:84)     at
> uk.me.parabola.imgfmt.app.map.MapReader.pointsForLevel(MapReader.ja
> va
> :119)     at
> uk.me.parabola.mkgmap.combiners.MdrBuilder.addPoints(MdrBuilder.jav
> a: 273)
>     at
> uk.me.parabola.mkgmap.combiners.MdrBuilder.onMapEnd(MdrBuilder.java
> :1 78)
>     at
> uk.me.parabola.mkgmap.main.Main.endOptions(Main.java:600)
>     at
> uk.me.parabola.mkgmap.CommandArgsReader.readArgs(CommandArgsReader.
> ja
> va:128)     at
> uk.me.parabola.mkgmap.main.Main.mainStart(Main.java:135)
>     at
> uk.me.parabola.mkgmap.main.Main.main(Main.java:106)"
>   
>               
>          When i use mkgmap 3702 an
> error
> message at the first step appears, the second step works fine:
> "SCHWERWIEGEND (ShapeMergeFilter):
> ..\Splitter\8804.osm.pbf:
> ignoring shape w ith id 364926659 and type 0x13 at resolution 24,
> it has 4
> points and has an empt y area" The OSM-Data is
> "nordrhein-westfalen.osm.pbf". An other map
> "Kanaran"
> works fine, without error. Whats the reason for this and what can i
> do?
> Best regards Arndt
>
> ___
> mkgmap-dev mailing list
> mkgmap-dev@.org
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
>
>
>
> --
> View this message in context: http://gis.19327.n8.nabble.com/Problem-
> with-r3706-tp5886790p5886799.html
> Sent from the Mkgmap Development mailing list archive at Nabble.com.
> ___
> 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
> > 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] Problem with r3706

[Gerd Petermann]

I guess we are hitting an edge case here, it seems that mkgmap overwrites data 
in the img file.


@Steve: Both RGNDisplay and GPSMapEdit "say" that the img file is corrupted, 
but I did not find yet

out where this happens.

Like Ticker I think the patch simply avoids the situation, it doesn't fix the 
problem.

If you are able to reproduce the problem with my test data, please help.


Gerd


Von: mkgmap-dev  im Auftrag von Gerd 
Petermann 
Gesendet: Mittwoch, 7. Dezember 2016 16:28:25
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Problem with r3706


Hi Ticker,


thanks, I'll have a look later.  Maybe it is related to one of my recent 
changes where

I changed some of those constraints.


Gerd


Von: mkgmap-dev  im Auftrag von Ticker 
Berkin 
Gesendet: Mittwoch, 7. Dezember 2016 16:08:22
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] Problem with r3706

Hi Gerd

I've been tearing my hair out over this one.

With the test data supplied, the SubDivision structure in the main
output .img file is incorrect. Just changing how areas are split (ie
relaxing the constraint that bounds are exactly representable at the
zoom/shift level) stops the crash, so this is what I've done in the
attached patch.

Sometime soon I'll try and work out when/where it goes wrong but I've
been looking in so many places, thinking I'd tracked down the problem,
only to find no difference, that I want to give up for a while.

Best wishes
Ticker


On Fri, 2016-12-02 at 15:49 +0100, Arndt Röhrig wrote:
> Hi,
> Thank you all for the support!
>
> Best regaards
>
> Ticker Berkin  hat am 2. Dezember 2016 um
> 15:22 geschrieben:
>
>
> I'll have a look. I didn't intentionally change extended type
> behaviour, but shapes will end up in different subdivisions with the
> option applied
>
> Ticker
>
>
> On Fri, 2016-12-02 at 07:09 -0700, Gerd Petermann wrote:
> I've got some more test data from Arndt, I've reproduced the
> assertion, here
> is the test data:
> http://files.mkgmap.org.uk/download/316/test.zip
>
> The problem seems to be caused by the new
> --order-by-decreasing-area option, if I remove that from the options
> file
> the problem is gone.
>
> @Ticker: Do you have time to analyse it? I assume the problem is that
> we set
> a flag like "extended type points exist" and later remove the
> corresponding
> data. Does that ring a bell?
>
> Gerd
>
> Arndt Röhrig wrote
> <!DOCTYPE html>
>
>
> Hello everybody, i use mkgmap r3706. It run 2 times. The first one
> makes
> the img-files. The second one makes the mdr/mdrx files. The first
> step
> works fine, without error-messages, but the second step produces an
> error
> message and crashes: "Exception in thread "main"
> java.lang.AssertionError: Invalid label offset found 1315595
>     at
> uk.me.parabola.imgfmt.app.lbl.LBLFileReader.fetchLabel(LBLFileReade
> r.
> java:87)     at
> uk.me.parabola.imgfmt.app.trergn.RGNFileReader.fetchPointsCommon(RG
> NF
> ileReader.java:123)     at
> uk.me.parabola.imgfmt.app.trergn.RGNFileReader.pointsForSubdiv(RGNF
> il
> eReader.java:84)     at
> uk.me.parabola.imgfmt.app.map.MapReader.pointsForLevel(MapReader.ja
> va
> :119)     at
> uk.me.parabola.mkgmap.combiners.MdrBuilder.addPoints(MdrBuilder.jav
> a: 273)
>     at
> uk.me.parabola.mkgmap.combiners.MdrBuilder.onMapEnd(MdrBuilder.java
> :1 78)
>     at
> uk.me.parabola.mkgmap.main.Main.endOptions(Main.java:600)
>     at
> uk.me.parabola.mkgmap.CommandArgsReader.readArgs(CommandArgsReader.
> ja
> va:128)     at
> uk.me.parabola.mkgmap.main.Main.mainStart(Main.java:135)
>     at
> uk.me.parabola.mkgmap.main.Main.main(Main.java:106)"
>   
>               
>          When i use mkgmap 3702 an
> error
> message at the first step appears, the second step works fine:
> "SCHWERWIEGEND (ShapeMergeFilter):
> ..\Splitter\8804.osm.pbf:
> ignoring shape w ith id 364926659 and type 0x13 at resolution 24,
> it has 4
> points and has an empt y area" The OSM-Data is
> "nordrhein-westfalen.osm.pbf". An other map
> "Kanaran"
> works fine, without error. Whats the reason for this and what can i
> do?
> Best regards Arndt
>
> ___
> mkgmap-dev mailing list
> mkgmap-dev@.org
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
>
>
>
> --
> View this message in context: http://gis.19327.n8.nabble.com/Problem-
> with-r3706-tp5886790p5886799.html
> Sent from the Mkgmap Development mailing list archive at Nabble.com.
> 

Re: [mkgmap-dev] Problem with r3706

[Steve Ratcliffe]

On 08/12/16 11:10, Gerd Petermann wrote:

@Steve: Both RGNDisplay and GPSMapEdit "say" that the img file is
corrupted, but I did not find yet

out where this happens.



I'm afraid I cannot reproduce the problem.  I downloaded sea and bounds
files fresh today.  Otherwise everything was as in the test.zip file
apart from the Copyright.txt.
The other difference may be I am using Linux and java 1.8.0_51

Could you upload a broken .img file for me please.



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

Re: [mkgmap-dev] Problem with r3706

[Gerd Petermann]

Hi Steve,


I've uploaded one which I created in eclipse, another one created with the 
first line in the batch file (v2):

http://files.mkgmap.org.uk/detail/320

http://files.mkgmap.org.uk/download/321/88099005.img


They are nearly identical, but maybe that also contains a hint.


Gerd


Von: mkgmap-dev  im Auftrag von Steve 
Ratcliffe 
Gesendet: Donnerstag, 8. Dezember 2016 14:28:12
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Problem with r3706

On 08/12/16 11:10, Gerd Petermann wrote:
> @Steve: Both RGNDisplay and GPSMapEdit "say" that the img file is
> corrupted, but I did not find yet
>
> out where this happens.
>

I'm afraid I cannot reproduce the problem.  I downloaded sea and bounds
files fresh today.  Otherwise everything was as in the test.zip file
apart from the Copyright.txt.
The other difference may be I am using Linux and java 1.8.0_51

Could you upload a broken .img file for me please.



..Steve
___
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] Problem with r3706

[Steve Ratcliffe]

On 08/12/16 13:39, Gerd Petermann wrote:

one created with the first line in the batch file


Ahh, I hadn't noticed the batch file.  If I follow that command line
then I can reproduce the problem.  That's good, I will try to figure
out what is happening.

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

Re: [mkgmap-dev] Problem with r3706

[Gerd Petermann]

Hi Steve


I think the problem is in the routines that create or write the TRE file,
esp. the Subdivsion info.
At offset 12080 the write routine doesn't write 2 bytes but the read routine
expects it.
Attached is a small patch that helps to find the place. I did not yet find
out how this can be fixed.
Any ideas?

Gerd


trefile.patch   



--
View this message in context: 
http://gis.19327.n8.nabble.com/Problem-with-r3706-tp5886790p5887786.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Problem with r3706

[Gerd Petermann]

Hi all,

I hope I found a fix for this problem with r3735 (and r3736).

Gerd


Arndt Röhrig wrote
> 
> 
> 
> Hello everybody, i use mkgmap r3706. It run 2 times. The first one makes
> the img-files. The second one makes the mdr/mdrx files. The first step
> works fine, without error-messages, but the second step produces an error
> message and crashes: "Exception in thread "main"
> java.lang.AssertionError: Invalid label offset found 1315595
>     at
> uk.me.parabola.imgfmt.app.lbl.LBLFileReader.fetchLabel(LBLFileReader.
> java:87)     at
> uk.me.parabola.imgfmt.app.trergn.RGNFileReader.fetchPointsCommon(RGNF
> ileReader.java:123)     at
> uk.me.parabola.imgfmt.app.trergn.RGNFileReader.pointsForSubdiv(RGNFil
> eReader.java:84)     at
> uk.me.parabola.imgfmt.app.map.MapReader.pointsForLevel(MapReader.java
> :119)     at
> uk.me.parabola.mkgmap.combiners.MdrBuilder.addPoints(MdrBuilder.java: 273)
>     at
> uk.me.parabola.mkgmap.combiners.MdrBuilder.onMapEnd(MdrBuilder.java:1 78)
>     at
> uk.me.parabola.mkgmap.main.Main.endOptions(Main.java:600)
>     at
> uk.me.parabola.mkgmap.CommandArgsReader.readArgs(CommandArgsReader.ja
> va:128)     at
> uk.me.parabola.mkgmap.main.Main.mainStart(Main.java:135)
>     at
> uk.me.parabola.mkgmap.main.Main.main(Main.java:106)"   
>               
>          When i use mkgmap 3702 an error
> message at the first step appears, the second step works fine:
> "SCHWERWIEGEND (ShapeMergeFilter): ..\Splitter\8804.osm.pbf:
> ignoring shape w ith id 364926659 and type 0x13 at resolution 24, it has 4
> points and has an empt y area" The OSM-Data is
> "nordrhein-westfalen.osm.pbf". An other map "Kanaran"
> works fine, without error. Whats the reason for this and what can i do?
> Best regards Arndt 
> 
> ___
> mkgmap-dev mailing list

> mkgmap-dev@.org

> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev





--
View this message in context: 
http://gis.19327.n8.nabble.com/Problem-with-r3706-tp5886790p5887905.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] Problem with roadNameConfig file

[Carlos Dávila]

Hi Gerd
It seems only first entry in prefix1 line is evaluated. I have a test 
file with

road1: highway=primary, name=Calle las Grullas
road2: highway=primary, name=Avenida Virgen de los Pastores
If roadNameConfig file contains the line
prefix1:es = "Calle", "Avenida"
I can search for "Las Grullas" and "Grullas" and not for "Calle..." as 
expected. I can also search for "Avenida Virgen...", but not for "Virgen..."

If roadNameConfig contains
prefix1:es = "Avenida", "Calle"
then I can search for "Virgen..." and "Calle las Grullas" but not for 
"Avenida Virgen..." nor "Grullas".

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

[mkgmap-dev] Problem with gmapi-builder

[Carlos Dávila]

Since mkgmap r4092 I get errors like "Missing part: 0 of GARMIN .RGN in 
IMG-file" or "Missing part: 0 of ~�?�.�� in IMG-file" when I use 
gmapi-builder.py to transform maps to gmap format. r4091 works fine with 
gmapi-builder.

Resulting *.gmapi folder is almost empty with r4092 and above.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] Problem with drive-on

[Carlos Dávila]

I am preparing an  areas.list file to split Oceania, so that each tile 
contains only roads driven on the same side. I have found a tile where 
all roads should be driven on left side, as it all lies within 
Indonesia, but mkgmap reports "Tile contains both drive-on-left (2695) 
and drive-on-right roads (57)". I have reduced tile size to narrow down 
the problem. These are its coordinates: -288768,6178816 to 
-210944,6219776. It includes two islands, right one is detected by 
mkgmap as right side driven, but it is left driven (to my knowledge). 
Any idea why this happens?



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

[mkgmap-dev] Problem with drive-on

[cdavilam]

 I am preparing an areas.list file to split Oceania, so that each tile 
contains only roads driven on the same side. I have found a tile where 
all roads should be driven on left side, as it all lies within 
Indonesia, but mkgmap reports "Tile contains both drive-on-left (2695) 
and drive-on-right roads (57)". I have reduced tile size to narrow down 
the problem. These are its coordinates: -288768,6178816 to 
-210944,6219776. It includes two islands, right one is detected by 
mkgmap as right side driven, but it is left driven (to my knowledge). 
Any idea why this happens?


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

Re: [mkgmap-dev] Problem merging images

[Steve Ratcliffe]

On 24/01/12 19:40, Johannes Formann wrote:

after using the adress index feature, the image merging doesn't work
anymore.

java '-Xms256m' '-Xmx2560m' '-jar' 'mkgmap.jar' '--gmapsupp'
'gmapsupp_Basiskarte.img' '/home/osm/radkarte/gmapsupp_Hoehenlinien.img'
'gmapsupp_RadRouten.img' 'gmapsupp_Steigungen.img'
'gmapsupp_fixMeLayer.img'

Is this known?
Is there a workaround if it is known? I'd like to keep the
"Layer"-Feature so I'd be able to choose the maps on my Oregon 450 "on
demand".


It is known that it is not possible to create a gmapsupp with an
address index by combining gmapsupp.img files.

I did not know that attempts to combine gmapsupp.img files that contain
an index will give you an empty file. This bug has actually been there
since r1334, but didn't show up since our gmapsupp files did not contain 
an index.


Since you cannot create an index while combining gmapsupp files, then a
workaround is to avoid creating the index in the individual files.

The attached patch solves the problem with combining in any case.

Thanks,

..Steve

Index: src/uk/me/parabola/mkgmap/combiners/FileInfo.java
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===
--- src/uk/me/parabola/mkgmap/combiners/FileInfo.java	(revision 2185)
+++ src/uk/me/parabola/mkgmap/combiners/FileInfo.java	(revision )
@@ -240,8 +240,9 @@
 } else if ("NOD".equals(ext)) {
 	info.setNodsize(ent.getSize());
 } else if ("MDR".equals(ext)) {
-	// It is not actually a regular img file, so change the kind.
+	// If there is no TRE then it is not actually a regular img file, so change the kind.
+	if (!hasTre)
-	info.setKind(MDR_KIND);
+		info.setKind(MDR_KIND);
 } else if ("MPS".equals(ext)) {
 	// This is a gmapsupp file containing several maps.
 	info.setKind(GMAPSUPP_KIND);
Index: src/uk/me/parabola/mkgmap/combiners/GmapsuppBuilder.java
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===
--- src/uk/me/parabola/mkgmap/combiners/GmapsuppBuilder.java	(revision 2185)
+++ src/uk/me/parabola/mkgmap/combiners/GmapsuppBuilder.java	(revision )
@@ -338,7 +338,7 @@
 		List entries = infs.list();
 		for (DirectoryEntry ent : entries) {
 			String ext = ent.getExt();
-			if (ext.equals("   ") || ext.equals("MPS"))
+			if (ext.equals("   ") || ext.equals("MPS") || ext.equals("MDR"))
 continue;
 
 			String inname = ent.getFullName();
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Problem merging images

[Johannes Formann]

Steve Ratcliffe  wrote:
> On 24/01/12 19:40, Johannes Formann wrote:
> > after using the adress index feature, the image merging doesn't work
> > anymore.

> The attached patch solves the problem with combining in any case.

Thanks, seems to work without any problem.

greetings

Johannes

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

Re: [mkgmap-dev] Problem with splitter

[GerdP]

Hi Matteo,

can you please describe the problem and what it is that
makes you believe that this is a splitter problem?

Gerd


Matteo Gottardi-2 wrote
> 
> Hi, I noticed a problem splitting the geofabrik pbf extract of Italy
> using the standard splitter-r200 options.
> 
> The area is at http://osm.org/go/0CmXpRz , and at
> http://www.gomatteo.net/10.jpg you can see how it look in
> QlandkarteGT.
> 
> The osm data seem ok, is a splitter problem?
> ___
> mkgmap-dev mailing list
> mkgmap-dev@.org
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> 


--
View this message in context: 
http://gis.19327.n5.nabble.com/Problem-with-splitter-tp886p911.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Problem with splitter

[Martin]

Looks like a coastline-problem.
Which parameter you use for mkgmap?

//Martin

Am 11.03.2012 um 22:10 schrieb GerdP:

> Hi Matteo,
> 
> can you please describe the problem and what it is that
> makes you believe that this is a splitter problem?
> 
> Gerd
> 
> 
> Matteo Gottardi-2 wrote
>> 
>> Hi, I noticed a problem splitting the geofabrik pbf extract of Italy
>> using the standard splitter-r200 options.
>> 
>> The area is at http://osm.org/go/0CmXpRz , and at
>> http://www.gomatteo.net/10.jpg you can see how it look in
>> QlandkarteGT.
>> 
>> The osm data seem ok, is a splitter problem?
>> ___
>> mkgmap-dev mailing list
>> mkgmap-dev@.org
>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>> 
> 
> 
> --
> View this message in context: 
> http://gis.19327.n5.nabble.com/Problem-with-splitter-tp886p911.html
> Sent from the Mkgmap Development mailing list archive at Nabble.com.
> ___
> 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] Problem with splitter

[Matteo Gottardi]

2012/3/11 Martin :
> Looks like a coastline-problem.
> Which parameter you use for mkgmap?

The options are:
- BEGIN -
code-page=1252
latin1
reduce-point-density=4
reduce-point-density-polygon=8
min-size-polygon=8
remove-short-arcs
merge-lines
add-pois-to-areas
pois-to-areas-placement
style-file=/home/matteo/opt/mkgmap_styles/teo_style
overview-mapname=teo
family-name=teo
mapname=63240001
family-id=6324
series-name=teo
country-name=Italia
country-abbr=IT
area-name=Italia
bounds=/home/matteo/opt/mkgmap_styles/bounds/europe
location-autofill=bounds
generate-sea=multipolygon
coastlinefile=/home/matteo/opt/mkgmap_styles/coastlines_europe-latest.osm.pbf
ignore-maxspeeds
ignore-turn-restrictions
tdbfile
- END -

The style file is the default one with some minor changes.

The lake is a multipoligon, tagged natural=water in the relation.

If it can help, you can download the bad tile at
http://www.gomatteo.net/63240018.osm.pbf , or download the italy file
from http://download.geofabrik.de/osm/europe/italy.osm.pbf and split
it.

-- 
* Matteo Gottardi | matg...@tin.it
* ICQ UIN 20381372
* Linux - the choice of a GNU generation
* GPG Fingerprint:
* B9EE 108F 52C8 D50C B667 B1F2 AB56 8A01 BA3D 36A1
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Problem with splitter

[Wolfgang Hammel]

Hi,

yes you are right, this is a splitter problem which
is already known.

As you can see in your example, the lake is split in a way that requires it
to be split more than once along the bounding rectangle.

see : http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2011q3/012119.html
and http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2011q3/012120.html

This prob. may occur, when the polygon to be split has more than two 
intersections with the bounding
rectangle and consists of some ways that have all their nodes outside 
the clipping rectangle.
As lakes and riverbanks may have curved outlines this can occasionally 
occur when the
bounding rectangle intersects the polygon in a way such that the clipped 
polygon falls into more than one
(or probably two) parts.

I usually take the following manual procedure to circumvent the problem 
when it occurs.

1. Run Tile splitter once and create a map
2. check the map for floodings along large riverbanks or lakes
3. edit the file areas.list (back up the original one createt by splitter)
 in order to move the border of the tiles away from the offending 
riverbank or lake.
But take care: you have to modify the corner coordinates of at least two
   areas in a consistent way in order to get a map without holes
   The modification of the coordinates should be done in multiples of 0x800.
3a. If needed you can visualize the splitting rectangles when you use 
the --write-kml option in step 1
   paste the complete contents of the generated kml-file here: 
http://display-kml.appspot.com/
4. rerun splitter using the option --split-file=
5. I use the same edited areas.list later again after I have downloaded 
new OSM-data
so this manual procedure has to be done only once for a certain area

Maybe someone has enough time to enhance TileSpltter, I unfortunately 
don't have at the moment.

But anyhow: All those working on splitter and mkgmap are doing a great 
job. Thank you!

Wolfgang


Am 11.03.2012 22:16, schrieb Martin:
> Looks like a coastline-problem.
> Which parameter you use for mkgmap?
>
> //Martin
>
> Am 11.03.2012 um 22:10 schrieb GerdP:
>
>> Hi Matteo,
>>
>> can you please describe the problem and what it is that
>> makes you believe that this is a splitter problem?
>>
>> Gerd
>>
>>
>> Matteo Gottardi-2 wrote
>>> Hi, I noticed a problem splitting the geofabrik pbf extract of Italy
>>> using the standard splitter-r200 options.
>>>
>>> The area is at http://osm.org/go/0CmXpRz , and at
>>> http://www.gomatteo.net/10.jpg you can see how it look in
>>> QlandkarteGT.
>>>
>>> The osm data seem ok, is a splitter problem?
>>> ___
>>> mkgmap-dev mailing list
>>> mkgmap-dev@.org
>>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>>>
>>
>> --
>> View this message in context: 
>> http://gis.19327.n5.nabble.com/Problem-with-splitter-tp886p911.html
>> Sent from the Mkgmap Development mailing list archive at Nabble.com.
>> ___
>> 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] Problem with splitter

[Matteo Gottardi]

2012/3/11 GerdP :
> Hi Matteo,
>
> can you please describe the problem and what it is that
> makes you believe that this is a splitter problem?

Hi, I don't speak english very well, so maybe a screenshot can help :)

If you look at http://www.gomatteo.net/out.jpeg you can see the
generated map. I marked with the red color the shape of the lake
(taken from the osm data).
As you can see there is some flooding, and the flooding end exactly at
the end of the splitted tile.

Thank you for your help,
  Teo
-- 
* Matteo Gottardi | matg...@tin.it
* ICQ UIN 20381372
* Linux - the choice of a GNU generation
* GPG Fingerprint:
* B9EE 108F 52C8 D50C B667 B1F2 AB56 8A01 BA3D 36A1
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Problem with splitter

[Gerd Petermann]

Hi Wolfgang,

I'll try to find a solution once the remaining problems in the performance 
branch are solved.

Gerd


> Date: Mon, 12 Mar 2012 00:14:42 +0100
> From: wolfgang.ham...@gmx.de
> To: mkgmap-dev@lists.mkgmap.org.uk
> Subject: Re: [mkgmap-dev] Problem with splitter
> 
> Hi,
> 
> yes you are right, this is a splitter problem which
> is already known.
> 
> As you can see in your example, the lake is split in a way that requires it
> to be split more than once along the bounding rectangle.
> 
> see : http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2011q3/012119.html
> and http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2011q3/012120.html
> 
> This prob. may occur, when the polygon to be split has more than two 
> intersections with the bounding
> rectangle and consists of some ways that have all their nodes outside 
> the clipping rectangle.
> As lakes and riverbanks may have curved outlines this can occasionally 
> occur when the
> bounding rectangle intersects the polygon in a way such that the clipped 
> polygon falls into more than one
> (or probably two) parts.
> 
> I usually take the following manual procedure to circumvent the problem 
> when it occurs.
> 
> 1. Run Tile splitter once and create a map
> 2. check the map for floodings along large riverbanks or lakes
> 3. edit the file areas.list (back up the original one createt by splitter)
>  in order to move the border of the tiles away from the offending 
> riverbank or lake.
> But take care: you have to modify the corner coordinates of at least two
>areas in a consistent way in order to get a map without holes
>The modification of the coordinates should be done in multiples of 0x800.
> 3a. If needed you can visualize the splitting rectangles when you use 
> the --write-kml option in step 1
>paste the complete contents of the generated kml-file here: 
> http://display-kml.appspot.com/
> 4. rerun splitter using the option --split-file=
> 5. I use the same edited areas.list later again after I have downloaded 
> new OSM-data
> so this manual procedure has to be done only once for a certain area
> 
> Maybe someone has enough time to enhance TileSpltter, I unfortunately 
> don't have at the moment.
> 
> But anyhow: All those working on splitter and mkgmap are doing a great 
> job. Thank you!
> 
> Wolfgang
> 
> 
> Am 11.03.2012 22:16, schrieb Martin:
> > Looks like a coastline-problem.
> > Which parameter you use for mkgmap?
> >
> > //Martin
> >
> > Am 11.03.2012 um 22:10 schrieb GerdP:
> >
> >> Hi Matteo,
> >>
> >> can you please describe the problem and what it is that
> >> makes you believe that this is a splitter problem?
> >>
> >> Gerd
> >>
> >>
> >> Matteo Gottardi-2 wrote
> >>> Hi, I noticed a problem splitting the geofabrik pbf extract of Italy
> >>> using the standard splitter-r200 options.
> >>>
> >>> The area is at http://osm.org/go/0CmXpRz , and at
> >>> http://www.gomatteo.net/10.jpg you can see how it look in
> >>> QlandkarteGT.
> >>>
> >>> The osm data seem ok, is a splitter problem?
> >>> ___
> >>> mkgmap-dev mailing list
> >>> mkgmap-dev@.org
> >>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> >>>
> >>
> >> --
> >> View this message in context: 
> >> http://gis.19327.n5.nabble.com/Problem-with-splitter-tp886p911.html
> >> Sent from the Mkgmap Development mailing list archive at Nabble.com.
> >> ___
> >> 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] Problem with splitter

[GerdP]

Hi Teo,

I tried to reproduce the problem with mkgmap trunk version r2248, but I get
different results, esp. I don't see this flooding.
I am using coastlines_europe-120128.osm.pbf, maybe your file is older?

Gerd




Matteo Gottardi-2 wrote
> 
> Hi, I noticed a problem splitting the geofabrik pbf extract of Italy
> using the standard splitter-r200 options.
> 
> The area is at http://osm.org/go/0CmXpRz , and at
> http://www.gomatteo.net/10.jpg you can see how it look in
> QlandkarteGT.
> 
> The osm data seem ok, is a splitter problem?
> ___
> mkgmap-dev mailing list
> mkgmap-dev@.org
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> 


--
View this message in context: 
http://gis.19327.n5.nabble.com/Problem-with-splitter-tp886p5556974.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Problem with splitter

[Thorsten Kukuk]

On Mon, Mar 12, GerdP wrote:

> Hi Teo,
> 
> I tried to reproduce the problem with mkgmap trunk version r2248, but I get
> different results, esp. I don't see this flooding.
> I am using coastlines_europe-120128.osm.pbf, maybe your file is older?

You need the exact same tiles, else you will not see it.
I think to reproduce you need the areas.list from Teo.

  Thorsten

> Matteo Gottardi-2 wrote
> > 
> > Hi, I noticed a problem splitting the geofabrik pbf extract of Italy
> > using the standard splitter-r200 options.
> > 
> > The area is at http://osm.org/go/0CmXpRz , and at
> > http://www.gomatteo.net/10.jpg you can see how it look in
> > QlandkarteGT.
> > 
> > The osm data seem ok, is a splitter problem?
> > ___
> > mkgmap-dev mailing list
> > mkgmap-dev@.org
> > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> > 
> 
> 
> --
> View this message in context: 
> http://gis.19327.n5.nabble.com/Problem-with-splitter-tp886p5556974.html
> Sent from the Mkgmap Development mailing list archive at Nabble.com.
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

-- 
Thorsten Kukuk, Project Manager/Release Manager SLES
SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Problem with splitter

[Gerd Petermann]

Hi Thorsten, 

I tried with his *.cfg and his 63240018.osm.pbf 
With splitter r200 I produced an identical 63240018.osm.pbf 

Why do you think that I should use his areas.list ?

Gerd

> Date: Mon, 12 Mar 2012 10:03:21 +0100
> From: ku...@suse.de
> To: mkgmap-dev@lists.mkgmap.org.uk
> Subject: Re: [mkgmap-dev] Problem with splitter
> 
> On Mon, Mar 12, GerdP wrote:
> 
> > Hi Teo,
> > 
> > I tried to reproduce the problem with mkgmap trunk version r2248, but I get
> > different results, esp. I don't see this flooding.
> > I am using coastlines_europe-120128.osm.pbf, maybe your file is older?
> 
> You need the exact same tiles, else you will not see it.
> I think to reproduce you need the areas.list from Teo.
> 
>   Thorsten
> 
> > Matteo Gottardi-2 wrote
> > > 
> > > Hi, I noticed a problem splitting the geofabrik pbf extract of Italy
> > > using the standard splitter-r200 options.
> > > 
> > > The area is at http://osm.org/go/0CmXpRz , and at
> > > http://www.gomatteo.net/10.jpg you can see how it look in
> > > QlandkarteGT.
> > > 
> > > The osm data seem ok, is a splitter problem?
> > > ___
> > > mkgmap-dev mailing list
> > > mkgmap-dev@.org
> > > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> > > 
> > 
> > 
> > --
> > View this message in context: 
> > http://gis.19327.n5.nabble.com/Problem-with-splitter-tp886p5556974.html
> > Sent from the Mkgmap Development mailing list archive at Nabble.com.
> > ___
> > mkgmap-dev mailing list
> > mkgmap-dev@lists.mkgmap.org.uk
> > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> 
> -- 
> Thorsten Kukuk, Project Manager/Release Manager SLES
> SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg
> GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
> ___
> 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] Problem with splitter

[Matteo Gottardi]

2012/3/12 GerdP :
> Hi Teo,
>
> I tried to reproduce the problem with mkgmap trunk version r2248, but I get
> different results, esp. I don't see this flooding.
> I am using coastlines_europe-120128.osm.pbf, maybe your file is older?

Hi Gerd,
my coastlines file was the same as yours, only with a different name :)

I did some tests. The results were a bit different because of my typ
and style files.
Using no typ file, the default style file and passing only
--generate-sea=multipolygon
--coastlinefile=coastlines_europe-120128.osm.pbf the result look like
this: http://www.gomatteo.net/17.png

PS: I would like to thank all the developers who spends their time
working on this great project, without mkgmap my gpsmap60c would be
useless :)

-- 
* Matteo Gottardi | matg...@tin.it
* ICQ UIN 20381372
* Linux - the choice of a GNU generation
* GPG Fingerprint:
* B9EE 108F 52C8 D50C B667 B1F2 AB56 8A01 BA3D 36A1
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev