Re: [mkgmap-dev] [Patch] unpaved roads

[Gerd Petermann]

The thread suggest different changes. The last one is this:
highway=* & mkgmap:unpaved=0 & smoothness ~ '.*(bad|horrible|impassable)'  { 
add mkgmap:road-speed = '-2' }

I think this will not work as there is no rule to set mkgmap:unpaved=0.
Did you mean mkgmap:unpaved!=1 instead?

Gerd

Von: mkgmap-dev  im Auftrag von lig 
fietser 
Gesendet: Mittwoch, 8. Februar 2017 19:26:52
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] [Patch] unpaved roads

I prefer v1, some remarks:


Please add paving_stones:30 (6012 cases)


I would suggest to set smoothness ~ '.*(very_bad|horrible|impassable)'  and 
give smoothness=bad a road_speed penalty. See 
https://forum.openstreetmap.org/viewtopic.php?id=57179

https://github.com/ligfietser/mkgmap-style-sheets/commit/1950f88900baaff405bab01887d7e7acbab799af




Hi all,

I've created two different patches, both treat surface=cobblestone as paved.
The major difference between v1 and v2 is in the handling of possibly 
conflicting attributes.
For example, I found quite a lot of ways with
highway=track, surface=paved , tracktype=3
in my hometown area.
With v1 and also with unpatched default style this will be treated as unpaved, 
with v2 it is paved.

The logic in v2 is that we first find surface tags which say "road is paved" 
and for those roads
we will never set mkgmap:unpaved=1.

Which one would you prefer?

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

[mkgmap-dev] Commit r3796: ExpressionReader.patch for preventing a crash when two

[svn commit]

Version mkgmap-r3796 was committed by gerd on Thu, 09 Feb 2017

ExpressionReader.patch for preventing a crash when two
regular expressions are used but the 'and' or 'or' separating them is
missing, for example:

landuse=meadow & (name~'[Mm]eadow'  name~'[Ff]ield') {delete name;}

The existing code crashes.

- Mike Baggaley

http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap=3796
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] [Patch] unpaved roads

[Dave Swarthout]

On Thu, Feb 9, 2017 at 1:26 AM, lig fietser  wrote:

I would suggest to set smoothness ~ '.*(very_bad|horrible|impassable)'  and
> give smoothness=bad a road_speed penalty.


+1

That's what I did in my styles. It's a useful compromise.


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Problems with -- gmapi (and possibly --gmapsupp also)

[Patrik Brunner]

Bingo !!

Gerd, you nailed it down. Was something easy to test and the result is 
that I now also have proper overview map in the gmap created by mkgmap !

Great, many thanks for your help and the hint/solution.

Sorry for the 'false' alarm the problem was, unfortunately that 
happens often, the 'thing' between the monitor and the back of the 
chair, the enduser... ;-)


Cheers
Patrik

On 08.02.2017 21:40, Gerd Petermann wrote:

Hi Patrik,

I think the overview map might be  missing because your cfg file contains option
remove-ovm-work-files
I guess the --gmapi option doesn't try to find/identify an existing overview 
map.

Gerd

Von: mkgmap-dev  im Auftrag von Patrik 
Brunner 
Gesendet: Mittwoch, 8. Februar 2017 21:33:53
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] Problems with -- gmapi (and possibly --gmapsupp also)

Steve,

in the process of building all different flavors of map (imagedir,
gmapsupp, gmapi) first the img files are built and afterward collected
together. The creation is done by calling mkgmap as follows (cfg file
attached):

java -Xmx1536M -Dfile.encoding=UTF-8 -jar 
D:/fzk/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/tools/mkgmap/mkgmap.jar 
 --max-jobs=2 -c Freizeitkarte_LUX.cfg --check-styles
Time started: Wed Feb 08 21:07:23 CET 2017
Found one style in 
D:/fzk/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/work/Freizeitkarte_LUX_fr/style/fzk
finished check-styles
Number of MapFailedExceptions: 0
Number of ExitExceptions: 0
Time finished: Wed Feb 08 21:08:04 CET 2017
Total time taken: 40429ms

After the the result is ok, the resulting map shown in BaseCamp (images
installed via Registry) does show the overview map. As far as I know the
overview map (as well as the flag to show the heigth profiles) are
stored in the tdb file, correct ?

Later in the normal process I call jmc_cli to convert the images into
gmapi format. This does not seem to screw the overview map (inside the
tdb file put into the gmap folder structure) and also shows the height
profiles.

But if I use the new functionality of mkgmap to convert the images into
gmapi format the height profiles and the overview map got lost. The tdb
and some other files (map files, but not the tile files) have a new
change time.
The missing heigth profiles could be fixed by just adding
--show-profiles=1 to the call, but I was not able to get the overview
map running. The actual call is:

java -Xmx1536M -Dfile.encoding=UTF-8 -jar D:/fzk/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/tools/mkgmap/mkgmap.jar  
--max-jobs=2 --index --code-page=1252 --gmapi --license-file=Freizeitkarte_LUX.license --product-id=1 --family-id=6442 
--family-name="Freizeitkarte_LUX" --series-name="Freizeitkarte_LUX" --description="Freizeitkarte_LUX 
(Release 17.02)" --overview-mapname="Freizeitkarte_LUX" --overview-mapnumber=6442 
--product-version="1702" 6442*.img 6442.TYP --tdbfile --show-profiles=1
Time started: Wed Feb 08 21:22:06 CET 2017
Number of MapFailedExceptions: 0
Number of ExitExceptions: 0
Time finished: Wed Feb 08 21:22:08 CET 2017
Total time taken: 1702ms

I was also trying to call it without the overview options which results
also in a map without overview map, but just with different (default)
filenames inside the gmap directory structure.
Calling it without --tdbfile also didn't help.

Any ideas ? Am I doing something wrong due to lack of understanding or
does mkgmap behave wrongly ?

Thanks and regards
Patrik

On 08.02.2017 11:42, Steve Ratcliffe wrote:

Hi Patrik


Folder structure looks the same as with for example jmc_cli.

I'm sorry but I still do not understand the problem.

If you create a map normally and then convert it with the garmin
converter does that gmapi map work?

The same map converted with mkgmap --gmapi, you are saying does
not work.

So if the first one works, but the second doesn't, then there must be
a difference between the two maps.

The only differences I know of are:

1. We do not create the top level osmmap.gmapi directory.
2. There are differences in the white space in the Info.xml file.

Or there is a difference in your case that I am not aware of.

If the problem is the first, then it is easy enough to fix.
I can't believe that it is the second, but you never know..

If there is another difference I need to know what it is.
If you could create a small map that does not work that you
could upload that would be helpful.

..Steve


It doesn't make a difference if I call mkgmap --gmapsupp with the
overview parameters (--overview-mapname=... --overview-mapnumber=...),
in no case I have overview maps.
The only difference is how the files are named inside the gmap directory
structure, either with the choosen names or with the default names.

Below shown call of mkgmap is the version without overview options...

Cheers
Patrik

On 06.02.2017 23:33, Steve Ratcliffe wrote:

Hi Patrik

Re: [mkgmap-dev] Problems with -- gmapi (and possibly --gmapsupp also)

[Steve Ratcliffe]

Hi

Yes good point that is likely the problem.

Creating the overview map is a second stage thing


Steve

On 8 February 2017 20:40:07 GMT+00:00, Gerd Petermann 
 wrote:
>Hi Patrik,
>
>I think the overview map might be  missing because your cfg file
>contains option
>remove-ovm-work-files
>I guess the --gmapi option doesn't try to find/identify an existing
>overview map.
>
>Gerd
>
>Von: mkgmap-dev  im Auftrag von
>Patrik Brunner 
>Gesendet: Mittwoch, 8. Februar 2017 21:33:53
>An: mkgmap-dev@lists.mkgmap.org.uk
>Betreff: Re: [mkgmap-dev] Problems with -- gmapi (and possibly
>--gmapsupp also)
>
>Steve,
>
>in the process of building all different flavors of map (imagedir,
>gmapsupp, gmapi) first the img files are built and afterward collected
>together. The creation is done by calling mkgmap as follows (cfg file
>attached):
>
>java -Xmx1536M -Dfile.encoding=UTF-8 -jar
>D:/fzk/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/tools/mkgmap/mkgmap.jar
> --max-jobs=2 -c Freizeitkarte_LUX.cfg --check-styles
>Time started: Wed Feb 08 21:07:23 CET 2017
>Found one style in
>D:/fzk/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/work/Freizeitkarte_LUX_fr/style/fzk
>finished check-styles
>Number of MapFailedExceptions: 0
>Number of ExitExceptions: 0
>Time finished: Wed Feb 08 21:08:04 CET 2017
>Total time taken: 40429ms
>
>After the the result is ok, the resulting map shown in BaseCamp (images
>installed via Registry) does show the overview map. As far as I know
>the
>overview map (as well as the flag to show the heigth profiles) are
>stored in the tdb file, correct ?
>
>Later in the normal process I call jmc_cli to convert the images into
>gmapi format. This does not seem to screw the overview map (inside the
>tdb file put into the gmap folder structure) and also shows the height
>profiles.
>
>But if I use the new functionality of mkgmap to convert the images into
>gmapi format the height profiles and the overview map got lost. The tdb
>and some other files (map files, but not the tile files) have a new
>change time.
>The missing heigth profiles could be fixed by just adding
>--show-profiles=1 to the call, but I was not able to get the overview
>map running. The actual call is:
>
>java -Xmx1536M -Dfile.encoding=UTF-8 -jar
>D:/fzk/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/tools/mkgmap/mkgmap.jar
>--max-jobs=2 --index --code-page=1252 --gmapi
>--license-file=Freizeitkarte_LUX.license --product-id=1
>--family-id=6442 --family-name="Freizeitkarte_LUX"
>--series-name="Freizeitkarte_LUX" --description="Freizeitkarte_LUX
>(Release 17.02)" --overview-mapname="Freizeitkarte_LUX"
>--overview-mapnumber=6442 --product-version="1702" 6442*.img
>6442.TYP --tdbfile --show-profiles=1
>Time started: Wed Feb 08 21:22:06 CET 2017
>Number of MapFailedExceptions: 0
>Number of ExitExceptions: 0
>Time finished: Wed Feb 08 21:22:08 CET 2017
>Total time taken: 1702ms
>
>I was also trying to call it without the overview options which results
>also in a map without overview map, but just with different (default)
>filenames inside the gmap directory structure.
>Calling it without --tdbfile also didn't help.
>
>Any ideas ? Am I doing something wrong due to lack of understanding or
>does mkgmap behave wrongly ?
>
>Thanks and regards
>Patrik
>
>On 08.02.2017 11:42, Steve Ratcliffe wrote:
>>
>> Hi Patrik
>>
>>> Folder structure looks the same as with for example jmc_cli.
>>
>> I'm sorry but I still do not understand the problem.
>>
>> If you create a map normally and then convert it with the garmin
>> converter does that gmapi map work?
>>
>> The same map converted with mkgmap --gmapi, you are saying does
>> not work.
>>
>> So if the first one works, but the second doesn't, then there must be
>> a difference between the two maps.
>>
>> The only differences I know of are:
>>
>> 1. We do not create the top level osmmap.gmapi directory.
>> 2. There are differences in the white space in the Info.xml file.
>>
>> Or there is a difference in your case that I am not aware of.
>>
>> If the problem is the first, then it is easy enough to fix.
>> I can't believe that it is the second, but you never know..
>>
>> If there is another difference I need to know what it is.
>> If you could create a small map that does not work that you
>> could upload that would be helpful.
>>
>> ..Steve
>>
>>> It doesn't make a difference if I call mkgmap --gmapsupp with the
>>> overview parameters (--overview-mapname=...
>--overview-mapnumber=...),
>>> in no case I have overview maps.
>>> The only difference is how the files are named inside the gmap
>directory
>>> structure, either with the choosen names or with the default names.
>>>
>>> Below shown call of mkgmap is the version without overview
>options...
>>>
>>> Cheers
>>> Patrik
>>>
>>> On 06.02.2017 23:33, Steve Ratcliffe wrote:
 Hi Patrik

> I've just noticed that 

Re: [mkgmap-dev] Problems with -- gmapi (and possibly --gmapsupp also)

[Gerd Petermann]

Hi Patrik,

I think the overview map might be  missing because your cfg file contains option
remove-ovm-work-files
I guess the --gmapi option doesn't try to find/identify an existing overview 
map.

Gerd

Von: mkgmap-dev  im Auftrag von Patrik 
Brunner 
Gesendet: Mittwoch, 8. Februar 2017 21:33:53
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] Problems with -- gmapi (and possibly --gmapsupp also)

Steve,

in the process of building all different flavors of map (imagedir,
gmapsupp, gmapi) first the img files are built and afterward collected
together. The creation is done by calling mkgmap as follows (cfg file
attached):

java -Xmx1536M -Dfile.encoding=UTF-8 -jar 
D:/fzk/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/tools/mkgmap/mkgmap.jar 
 --max-jobs=2 -c Freizeitkarte_LUX.cfg --check-styles
Time started: Wed Feb 08 21:07:23 CET 2017
Found one style in 
D:/fzk/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/work/Freizeitkarte_LUX_fr/style/fzk
finished check-styles
Number of MapFailedExceptions: 0
Number of ExitExceptions: 0
Time finished: Wed Feb 08 21:08:04 CET 2017
Total time taken: 40429ms

After the the result is ok, the resulting map shown in BaseCamp (images
installed via Registry) does show the overview map. As far as I know the
overview map (as well as the flag to show the heigth profiles) are
stored in the tdb file, correct ?

Later in the normal process I call jmc_cli to convert the images into
gmapi format. This does not seem to screw the overview map (inside the
tdb file put into the gmap folder structure) and also shows the height
profiles.

But if I use the new functionality of mkgmap to convert the images into
gmapi format the height profiles and the overview map got lost. The tdb
and some other files (map files, but not the tile files) have a new
change time.
The missing heigth profiles could be fixed by just adding
--show-profiles=1 to the call, but I was not able to get the overview
map running. The actual call is:

java -Xmx1536M -Dfile.encoding=UTF-8 -jar 
D:/fzk/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/tools/mkgmap/mkgmap.jar 
 --max-jobs=2 --index --code-page=1252 --gmapi 
--license-file=Freizeitkarte_LUX.license --product-id=1 --family-id=6442 
--family-name="Freizeitkarte_LUX" --series-name="Freizeitkarte_LUX" 
--description="Freizeitkarte_LUX (Release 17.02)" 
--overview-mapname="Freizeitkarte_LUX" --overview-mapnumber=6442 
--product-version="1702" 6442*.img 6442.TYP --tdbfile --show-profiles=1
Time started: Wed Feb 08 21:22:06 CET 2017
Number of MapFailedExceptions: 0
Number of ExitExceptions: 0
Time finished: Wed Feb 08 21:22:08 CET 2017
Total time taken: 1702ms

I was also trying to call it without the overview options which results
also in a map without overview map, but just with different (default)
filenames inside the gmap directory structure.
Calling it without --tdbfile also didn't help.

Any ideas ? Am I doing something wrong due to lack of understanding or
does mkgmap behave wrongly ?

Thanks and regards
Patrik

On 08.02.2017 11:42, Steve Ratcliffe wrote:
>
> Hi Patrik
>
>> Folder structure looks the same as with for example jmc_cli.
>
> I'm sorry but I still do not understand the problem.
>
> If you create a map normally and then convert it with the garmin
> converter does that gmapi map work?
>
> The same map converted with mkgmap --gmapi, you are saying does
> not work.
>
> So if the first one works, but the second doesn't, then there must be
> a difference between the two maps.
>
> The only differences I know of are:
>
> 1. We do not create the top level osmmap.gmapi directory.
> 2. There are differences in the white space in the Info.xml file.
>
> Or there is a difference in your case that I am not aware of.
>
> If the problem is the first, then it is easy enough to fix.
> I can't believe that it is the second, but you never know..
>
> If there is another difference I need to know what it is.
> If you could create a small map that does not work that you
> could upload that would be helpful.
>
> ..Steve
>
>> It doesn't make a difference if I call mkgmap --gmapsupp with the
>> overview parameters (--overview-mapname=... --overview-mapnumber=...),
>> in no case I have overview maps.
>> The only difference is how the files are named inside the gmap directory
>> structure, either with the choosen names or with the default names.
>>
>> Below shown call of mkgmap is the version without overview options...
>>
>> Cheers
>> Patrik
>>
>> On 06.02.2017 23:33, Steve Ratcliffe wrote:
>>> Hi Patrik
>>>
 I've just noticed that the quite new option --gmapi does not work
 properly regarding overview maps:
 - I first build the img files where all is correct, overview maps are
 properly built and set at the different needed locations (*.tdb file,
 elsewhere ?)
 - running mkgmap with the option --gmapi (complete output shown 

Re: [mkgmap-dev] [Patch] unpaved roads

[lig fietser]

I prefer v1, some remarks:


Please add paving_stones:30 (6012 cases)


I would suggest to set smoothness ~ '.*(very_bad|horrible|impassable)'  and 
give smoothness=bad a road_speed penalty. See 
https://forum.openstreetmap.org/viewtopic.php?id=57179

https://github.com/ligfietser/mkgmap-style-sheets/commit/1950f88900baaff405bab01887d7e7acbab799af




Hi all,

I've created two different patches, both treat surface=cobblestone as paved.
The major difference between v1 and v2 is in the handling of possibly 
conflicting attributes.
For example, I found quite a lot of ways with
highway=track, surface=paved , tracktype=3
in my hometown area.
With v1 and also with unpatched default style this will be treated as unpaved, 
with v2 it is paved.

The logic in v2 is that we first find surface tags which say "road is paved" 
and for those roads
we will never set mkgmap:unpaved=1.

Which one would you prefer?

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

Re: [mkgmap-dev] unit test fails in branch

[Gerd Petermann]

Hi Ticker,

I've just executed at clean dist test with r3795 and got no problem.
Note that the TRE size also depends on the value returned by 
Version.getSvnVersion();

Gerd



Von: mkgmap-dev  im Auftrag von Ticker 
Berkin 
Gesendet: Mittwoch, 8. Februar 2017 18:24:20
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] unit test fails in branch

Hi Gerd

Strange - I don't get this failure, but there was a place were I set
something to null because there wasn't a good value for it and I
thought it would be a mistake for later code to use it. I've set it to
something harmless.

but I still get:
junit.framework.AssertionFailedError: TRE size
Expected: between <768> and <772>
 but: was <773>
  at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
  at func.SimpleTest.testPolish(SimpleTest.java:104)

I thought you'd just committed a change to stop this.

Ticker


On Wed, 2017-02-08 at 16:23 +, Gerd Petermann wrote:
> Hi Ticker,
>
> I've fixed another one with r3794, but on my (Windows) machine
> TestSourceTest fails:
> Time started: Wed Feb 08 17:22:56 CET 2017
> java.lang.NullPointerException
> at
> uk.me.parabola.mkgmap.build.MapSplitter.addAreasToList(MapSplitter.ja
> va:159)
> at
> uk.me.parabola.mkgmap.build.MapSplitter.addAreasToList(MapSplitter.ja
> va:187)
> at
> uk.me.parabola.mkgmap.build.MapSplitter.addAreasToList(MapSplitter.ja
> va:181)
> at
> uk.me.parabola.mkgmap.build.MapSplitter.addAreasToList(MapSplitter.ja
> va:181)
> at
> uk.me.parabola.mkgmap.build.MapSplitter.addAreasToList(MapSplitter.ja
> va:181)
> at
> uk.me.parabola.mkgmap.build.MapSplitter.addAreasToList(MapSplitter.ja
> va:181)
> at
> uk.me.parabola.mkgmap.build.MapSplitter.addAreasToList(MapSplitter.ja
> va:181)
> at
> uk.me.parabola.mkgmap.build.MapSplitter.split(MapSplitter.java:113)
> at
> uk.me.parabola.mkgmap.build.MapBuilder.makeMapAreas(MapBuilder.java:6
> 98)
> at
> uk.me.parabola.mkgmap.build.MapBuilder.makeMap(MapBuilder.java:234)
> at
> uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:107)
> at
> uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:69)
> at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:265)
> at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:1)
> at java.util.concurrent.FutureTask.run(Unknown Source)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown
> Source)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown
> Source)
> at java.lang.Thread.run(Unknown Source)
> Exiting - if you want to carry on regardless, use the --keep-going
> option
> Number of ExitExceptions: 1
>
> Gerd
> 
> Von: mkgmap-dev  im Auftrag
> von Ticker Berkin 
> Gesendet: Mittwoch, 8. Februar 2017 16:58:24
> An: mkgmap-dev@lists.mkgmap.org.uk
> Betreff: Re: [mkgmap-dev] unit test fails in branch
>
> Fixed this.
>
> svn commit comment should have been:
> "Merge in trunk and cope with mapSource without bounds"
>
> Ticker
>
>
> On Wed, 2017-02-08 at 08:46 +, Gerd Petermann wrote:
> > Hi Ticker,
> >
> > please check:
> > The unit test testCombiningSupps() in class GmapsuppTest fails:
> > SCHWERWIEGEND (MapFailedException): (thrown in Area.split()) Area
> > split shift align problems
> > uk.me.parabola.imgfmt.MapFailedException: Area split shift align
> > problems
> >   at uk.me.parabola.imgfmt.app.Area.split(Area.java:174)
> >   at
> > uk.me.parabola.mkgmap.build.MapArea.split(MapArea.java:206)
> >   at
> > uk.me.parabola.mkgmap.build.MapSplitter.splitMaxSize(MapSplitter.ja
> > va
> > :234)
> >   at
> > uk.me.parabola.mkgmap.build.MapSplitter.split(MapSplitter.java:103)
> >   at
> > uk.me.parabola.mkgmap.build.MapBuilder.makeMapAreas(MapBuilder.java
> > :6
> > 98)
> >   at
> > uk.me.parabola.mkgmap.build.MapBuilder.makeMap(MapBuilder.java:234)
> >   at
> > uk.me.parabola.mkgmap.combiners.OverviewBuilder.writeOverviewMap(Ov
> > er
> > viewBuilder.java:184)
> >   at
> > uk.me.parabola.mkgmap.combiners.OverviewBuilder.onFinish(OverviewBu
> > il
> > der.java:91)
> >   at uk.me.parabola.mkgmap.main.Main.endOptions(Main.java:620)
> >   at
> > uk.me.parabola.mkgmap.CommandArgsReader.readArgs(CommandArgsReader.
> > ja
> > va:128)
> >   at uk.me.parabola.mkgmap.main.Main.mainStart(Main.java:138)
> >   at
> > uk.me.parabola.mkgmap.main.Main.mainNoSystemExit(Main.java:105)
> >   at
> > func.files.GmapsuppTest.testCombiningSupps(GmapsuppTest.java:129)
> >   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
> > Method)
> >   at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown
> > Source)
> >   at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown
> > 

Re: [mkgmap-dev] unit test fails in branch

[Gerd Petermann]

Hi Ticker,

I think you get this in SimpleTest, I've changed SimpleRouteTest

Gerd

Von: mkgmap-dev  im Auftrag von Ticker 
Berkin 
Gesendet: Mittwoch, 8. Februar 2017 18:24:20
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] unit test fails in branch

Hi Gerd

Strange - I don't get this failure, but there was a place were I set
something to null because there wasn't a good value for it and I
thought it would be a mistake for later code to use it. I've set it to
something harmless.

but I still get:
junit.framework.AssertionFailedError: TRE size
Expected: between <768> and <772>
 but: was <773>
  at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
  at func.SimpleTest.testPolish(SimpleTest.java:104)

I thought you'd just committed a change to stop this.

Ticker


On Wed, 2017-02-08 at 16:23 +, Gerd Petermann wrote:
> Hi Ticker,
>
> I've fixed another one with r3794, but on my (Windows) machine
> TestSourceTest fails:
> Time started: Wed Feb 08 17:22:56 CET 2017
> java.lang.NullPointerException
> at
> uk.me.parabola.mkgmap.build.MapSplitter.addAreasToList(MapSplitter.ja
> va:159)
> at
> uk.me.parabola.mkgmap.build.MapSplitter.addAreasToList(MapSplitter.ja
> va:187)
> at
> uk.me.parabola.mkgmap.build.MapSplitter.addAreasToList(MapSplitter.ja
> va:181)
> at
> uk.me.parabola.mkgmap.build.MapSplitter.addAreasToList(MapSplitter.ja
> va:181)
> at
> uk.me.parabola.mkgmap.build.MapSplitter.addAreasToList(MapSplitter.ja
> va:181)
> at
> uk.me.parabola.mkgmap.build.MapSplitter.addAreasToList(MapSplitter.ja
> va:181)
> at
> uk.me.parabola.mkgmap.build.MapSplitter.addAreasToList(MapSplitter.ja
> va:181)
> at
> uk.me.parabola.mkgmap.build.MapSplitter.split(MapSplitter.java:113)
> at
> uk.me.parabola.mkgmap.build.MapBuilder.makeMapAreas(MapBuilder.java:6
> 98)
> at
> uk.me.parabola.mkgmap.build.MapBuilder.makeMap(MapBuilder.java:234)
> at
> uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:107)
> at
> uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:69)
> at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:265)
> at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:1)
> at java.util.concurrent.FutureTask.run(Unknown Source)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown
> Source)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown
> Source)
> at java.lang.Thread.run(Unknown Source)
> Exiting - if you want to carry on regardless, use the --keep-going
> option
> Number of ExitExceptions: 1
>
> Gerd
> 
> Von: mkgmap-dev  im Auftrag
> von Ticker Berkin 
> Gesendet: Mittwoch, 8. Februar 2017 16:58:24
> An: mkgmap-dev@lists.mkgmap.org.uk
> Betreff: Re: [mkgmap-dev] unit test fails in branch
>
> Fixed this.
>
> svn commit comment should have been:
> "Merge in trunk and cope with mapSource without bounds"
>
> Ticker
>
>
> On Wed, 2017-02-08 at 08:46 +, Gerd Petermann wrote:
> > Hi Ticker,
> >
> > please check:
> > The unit test testCombiningSupps() in class GmapsuppTest fails:
> > SCHWERWIEGEND (MapFailedException): (thrown in Area.split()) Area
> > split shift align problems
> > uk.me.parabola.imgfmt.MapFailedException: Area split shift align
> > problems
> >   at uk.me.parabola.imgfmt.app.Area.split(Area.java:174)
> >   at
> > uk.me.parabola.mkgmap.build.MapArea.split(MapArea.java:206)
> >   at
> > uk.me.parabola.mkgmap.build.MapSplitter.splitMaxSize(MapSplitter.ja
> > va
> > :234)
> >   at
> > uk.me.parabola.mkgmap.build.MapSplitter.split(MapSplitter.java:103)
> >   at
> > uk.me.parabola.mkgmap.build.MapBuilder.makeMapAreas(MapBuilder.java
> > :6
> > 98)
> >   at
> > uk.me.parabola.mkgmap.build.MapBuilder.makeMap(MapBuilder.java:234)
> >   at
> > uk.me.parabola.mkgmap.combiners.OverviewBuilder.writeOverviewMap(Ov
> > er
> > viewBuilder.java:184)
> >   at
> > uk.me.parabola.mkgmap.combiners.OverviewBuilder.onFinish(OverviewBu
> > il
> > der.java:91)
> >   at uk.me.parabola.mkgmap.main.Main.endOptions(Main.java:620)
> >   at
> > uk.me.parabola.mkgmap.CommandArgsReader.readArgs(CommandArgsReader.
> > ja
> > va:128)
> >   at uk.me.parabola.mkgmap.main.Main.mainStart(Main.java:138)
> >   at
> > uk.me.parabola.mkgmap.main.Main.mainNoSystemExit(Main.java:105)
> >   at
> > func.files.GmapsuppTest.testCombiningSupps(GmapsuppTest.java:129)
> >   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
> > Method)
> >   at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown
> > Source)
> >   at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown
> > Source)
> >   at java.lang.reflect.Method.invoke(Unknown Source)
> >   at
> > 

Re: [mkgmap-dev] unit test fails in branch

[Ticker Berkin]

Hi Gerd

Strange - I don't get this failure, but there was a place were I set
something to null because there wasn't a good value for it and I
thought it would be a mistake for later code to use it. I've set it to
something harmless.

but I still get:
junit.framework.AssertionFailedError: TRE size
Expected: between <768> and <772>
 but: was <773>
  at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
  at func.SimpleTest.testPolish(SimpleTest.java:104)

I thought you'd just committed a change to stop this.

Ticker


On Wed, 2017-02-08 at 16:23 +, Gerd Petermann wrote:
> Hi Ticker,
> 
> I've fixed another one with r3794, but on my (Windows) machine
> TestSourceTest fails:
> Time started: Wed Feb 08 17:22:56 CET 2017
> java.lang.NullPointerException
> at
> uk.me.parabola.mkgmap.build.MapSplitter.addAreasToList(MapSplitter.ja
> va:159)
> at
> uk.me.parabola.mkgmap.build.MapSplitter.addAreasToList(MapSplitter.ja
> va:187)
> at
> uk.me.parabola.mkgmap.build.MapSplitter.addAreasToList(MapSplitter.ja
> va:181)
> at
> uk.me.parabola.mkgmap.build.MapSplitter.addAreasToList(MapSplitter.ja
> va:181)
> at
> uk.me.parabola.mkgmap.build.MapSplitter.addAreasToList(MapSplitter.ja
> va:181)
> at
> uk.me.parabola.mkgmap.build.MapSplitter.addAreasToList(MapSplitter.ja
> va:181)
> at
> uk.me.parabola.mkgmap.build.MapSplitter.addAreasToList(MapSplitter.ja
> va:181)
> at
> uk.me.parabola.mkgmap.build.MapSplitter.split(MapSplitter.java:113)
> at
> uk.me.parabola.mkgmap.build.MapBuilder.makeMapAreas(MapBuilder.java:6
> 98)
> at
> uk.me.parabola.mkgmap.build.MapBuilder.makeMap(MapBuilder.java:234)
> at
> uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:107)
> at
> uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:69)
> at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:265)
> at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:1)
> at java.util.concurrent.FutureTask.run(Unknown Source)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown
> Source)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown
> Source)
> at java.lang.Thread.run(Unknown Source)
> Exiting - if you want to carry on regardless, use the --keep-going
> option
> Number of ExitExceptions: 1
> 
> Gerd
> 
> Von: mkgmap-dev  im Auftrag
> von Ticker Berkin 
> Gesendet: Mittwoch, 8. Februar 2017 16:58:24
> An: mkgmap-dev@lists.mkgmap.org.uk
> Betreff: Re: [mkgmap-dev] unit test fails in branch
> 
> Fixed this.
> 
> svn commit comment should have been:
> "Merge in trunk and cope with mapSource without bounds"
> 
> Ticker
> 
> 
> On Wed, 2017-02-08 at 08:46 +, Gerd Petermann wrote:
> > Hi Ticker,
> > 
> > please check:
> > The unit test testCombiningSupps() in class GmapsuppTest fails:
> > SCHWERWIEGEND (MapFailedException): (thrown in Area.split()) Area
> > split shift align problems
> > uk.me.parabola.imgfmt.MapFailedException: Area split shift align
> > problems
> >   at uk.me.parabola.imgfmt.app.Area.split(Area.java:174)
> >   at
> > uk.me.parabola.mkgmap.build.MapArea.split(MapArea.java:206)
> >   at
> > uk.me.parabola.mkgmap.build.MapSplitter.splitMaxSize(MapSplitter.ja
> > va
> > :234)
> >   at
> > uk.me.parabola.mkgmap.build.MapSplitter.split(MapSplitter.java:103)
> >   at
> > uk.me.parabola.mkgmap.build.MapBuilder.makeMapAreas(MapBuilder.java
> > :6
> > 98)
> >   at
> > uk.me.parabola.mkgmap.build.MapBuilder.makeMap(MapBuilder.java:234)
> >   at
> > uk.me.parabola.mkgmap.combiners.OverviewBuilder.writeOverviewMap(Ov
> > er
> > viewBuilder.java:184)
> >   at
> > uk.me.parabola.mkgmap.combiners.OverviewBuilder.onFinish(OverviewBu
> > il
> > der.java:91)
> >   at uk.me.parabola.mkgmap.main.Main.endOptions(Main.java:620)
> >   at
> > uk.me.parabola.mkgmap.CommandArgsReader.readArgs(CommandArgsReader.
> > ja
> > va:128)
> >   at uk.me.parabola.mkgmap.main.Main.mainStart(Main.java:138)
> >   at
> > uk.me.parabola.mkgmap.main.Main.mainNoSystemExit(Main.java:105)
> >   at
> > func.files.GmapsuppTest.testCombiningSupps(GmapsuppTest.java:129)
> >   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
> > Method)
> >   at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown
> > Source)
> >   at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown
> > Source)
> >   at java.lang.reflect.Method.invoke(Unknown Source)
> >   at
> > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(Framewo
> > rk
> > Method.java:50)
> >   at
> > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveC
> > al
> > lable.java:12)
> >   at
> > org.junit.runners.model.FrameworkMethod.invokeExplosively(Framework
> > Me
> > thod.java:47)
> >   at
> > 

Re: [mkgmap-dev] unpaved roads

[Nuno Pedrosa]

Carlos, I see your point.

Thank you,
Nuno Pedrosa.

> On 8 Feb 2017, at 12:15, Carlos Dávila  wrote:
> 
> I don't see the point of that example. It's a place in the countryside, so 
> people going there is probably aware they may need to travel over a track. 
> Anyway, there's a paved road that leads you only 220 m away from Las Lomas, 
> so you'll probably be able to reach the place even if unpaved roads are 
> disabled in the GPS. I'm sorry, but I don't see the need to mark unpaved ways 
> as paved.
> 
> El 08/02/17 a las 12:27, Nuno Pedrosa escribió:
>> Ok. But that will mean that in a generic map, a lot of places will be 
>> unroutable if the GPS is avoiding all unpaved roads. To reach them, the user 
>> will need to allow unpaved roads in the route. This will mean routing 
>> through sand roads and gravel roads alike.
>> It would be great if the GPS could handle semi-paved roads, as was 
>> mentioned, but it can't.
>> 
>> In a generic map, what will be most important? To reach the destination, or 
>> to avoid getting dirt in the car?
>> In Cadiz, Finca Las Lomas, s/n, 11179 Vejer de la Frontera, Cádiz, Spain, 
>> would be mostly unreachable if avoiding gravel roads.
>> https://www.google.pt/maps/place/Escuelas+Profesionales+de+la+Sagrada+Familia+Nuestra+Señora+del+Buen+Consejo+de+las+Lomas/@36.2938403,-5.8821947,17z/data=!3m1!4b1!4m5!3m4!1s0xd0c5074acf746b9:0x32a4ea0ba5f0c3d!8m2!3d36.293836!4d-5.880006
>>  
>> 
>> There are lots of places like this.
>> 
>> A side-thought: paved roads aren’t always the best option for a given 
>> region. They are more expensive to build and when they degrade, they get 
>> “hard holes”(*) and fixing them up will usually create bumps in every hole. 
>> If the traffic is low, gravel roads will probably be a better option and 
>> better yet if rain is uncommon, as is the case in southern Europe.
>> 
>> Nuno Pedrosa
>> 
>> (*) by “hard holes”, I mean pot-holes where the edges are very steep and the 
>> wheels will crash into it. Gravel roads tend to create pot-holes with soft 
>> edges, a lot easier to drive over.
>> 
>> 
>> 
>>> On 7 Feb 2017, at 11:39, Carlos Dávila >> > wrote:
>>> 
>>> I don't agree with you. I think default style is a generic style, and as 
>>> such, it shouldn't do much guess but use the strict meaning of tags. 
>>> Gravel, fine_gravel, ice, etc. are strictly unpaved and I would mark them 
>>> as such in default style. More specific uses (mtb/race bicycle/4wd...) 
>>> require specific maps and thus specific styles.
>>> @Mark: I'm also cyclist and for mtb use your "raining" point of view of 
>>> paved/unpaved is important to be considered.
>>> 
>>> El 07/02/17 a las 11:57, Nuno Pedrosa escribió:
 Hi! In Portugal, Spain and surely a little all around, unpaved gravel 
 roads are common, even on urban neighbourhoods.
 These are quite drivable and they will often be the only way to get to 
 some places. They are also suitable to all vehicles, even if they will get 
 covered in dirt.
 There are also a lot of paths going through sand (forest roads) and these 
 will unsuitable to most vehicles (even a lot of 4x4s), regardless of their 
 width.
 
 I find that while driving, the real issue will be the road conditions and 
 width. Will the unpaved road be wide enough for a car or light truck? Will 
 it have deep tracks due to soil erosion? Will the surface be solid enough 
 to drive in a regular car?
 
 So, in real world GPS usage, I would like unpaved to mean “narrow, earth 
 roads”, while paved would mean any road suitable to all regular vehicles.
 Example: due to wind farms being built in a lot of hill ranges, large, 
 unpaved roads were built. These are gravel, wide roads, and often are a 
 better option to the paved, sinuous mountain roads that go around every 
 nook and cranny in the valleys.
 
 So, I think that fine_gravel, salt and ice should still be “paved”.
 
 Nuno Pedrosa.
 
 PS: Sorry to “butt in” the talk. I’m usually silent in this list, though I 
 read most of the discussions. Your work is amazing and I find that I can 
 add little to what is being discussed, so I try to keep my “noise” to a 
 minimum!
 
 
> On 7 Feb 2017, at 09:40, lig fietser  > wrote:
> 
> I'd call that semi-paved but Garmin doesn't have such category 
> unfortunately. Since the default style main focus is on motor vehicles 
> I'd suggest to add surfaces like fine_gravel, salt, ice to the unpaved 
> 

Re: [mkgmap-dev] unpaved roads

[Nuno Pedrosa]

Hi Gerd,

I’m not sure about that, but it makes sense.

Thank you,
Nuno Pedrosa.

> On 8 Feb 2017, at 12:11, Gerd Petermann  
> wrote:
> 
> Hu Nuna,
> 
> If I got that right the Garmin algo uses unpaved roads if the target is only 
> reachable via unpaved
> roads, at least if the target itself is an unpaved road.
> 
> Gerd
> 
> Von: mkgmap-dev  im Auftrag von Nuno 
> Pedrosa 
> Gesendet: Mittwoch, 8. Februar 2017 12:27:11
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] unpaved roads
> 
> Ok. But that will mean that in a generic map, a lot of places will be 
> unroutable if the GPS is avoiding all unpaved roads. To reach them, the user 
> will need to allow unpaved roads in the route. This will mean routing through 
> sand roads and gravel roads alike.
> It would be great if the GPS could handle semi-paved roads, as was mentioned, 
> but it can't.
> 
> In a generic map, what will be most important? To reach the destination, or 
> to avoid getting dirt in the car?
> In Cadiz, Finca Las Lomas, s/n, 11179 Vejer de la Frontera, Cádiz, Spain, 
> would be mostly unreachable if avoiding gravel roads.
> https://www.google.pt/maps/place/Escuelas+Profesionales+de+la+Sagrada+Familia+Nuestra+Señora+del+Buen+Consejo+de+las+Lomas/@36.2938403,-5.8821947,17z/data=!3m1!4b1!4m5!3m4!1s0xd0c5074acf746b9:0x32a4ea0ba5f0c3d!8m2!3d36.293836!4d-5.880006
> There are lots of places like this.
> 
> A side-thought: paved roads aren’t always the best option for a given region. 
> They are more expensive to build and when they degrade, they get “hard 
> holes”(*) and fixing them up will usually create bumps in every hole. If the 
> traffic is low, gravel roads will probably be a better option and better yet 
> if rain is uncommon, as is the case in southern Europe.
> 
> Nuno Pedrosa
> 
> (*) by “hard holes”, I mean pot-holes where the edges are very steep and the 
> wheels will crash into it. Gravel roads tend to create pot-holes with soft 
> edges, a lot easier to drive over.
> 
> 
> 
> On 7 Feb 2017, at 11:39, Carlos Dávila 
> > wrote:
> 
> I don't agree with you. I think default style is a generic style, and as 
> such, it shouldn't do much guess but use the strict meaning of tags. Gravel, 
> fine_gravel, ice, etc. are strictly unpaved and I would mark them as such in 
> default style. More specific uses (mtb/race bicycle/4wd...) require specific 
> maps and thus specific styles.
> @Mark: I'm also cyclist and for mtb use your "raining" point of view of 
> paved/unpaved is important to be considered.
> 
> El 07/02/17 a las 11:57, Nuno Pedrosa escribió:
> Hi! In Portugal, Spain and surely a little all around, unpaved gravel roads 
> are common, even on urban neighbourhoods.
> These are quite drivable and they will often be the only way to get to some 
> places. They are also suitable to all vehicles, even if they will get covered 
> in dirt.
> There are also a lot of paths going through sand (forest roads) and these 
> will unsuitable to most vehicles (even a lot of 4x4s), regardless of their 
> width.
> 
> I find that while driving, the real issue will be the road conditions and 
> width. Will the unpaved road be wide enough for a car or light truck? Will it 
> have deep tracks due to soil erosion? Will the surface be solid enough to 
> drive in a regular car?
> 
> So, in real world GPS usage, I would like unpaved to mean “narrow, earth 
> roads”, while paved would mean any road suitable to all regular vehicles.
> Example: due to wind farms being built in a lot of hill ranges, large, 
> unpaved roads were built. These are gravel, wide roads, and often are a 
> better option to the paved, sinuous mountain roads that go around every nook 
> and cranny in the valleys.
> 
> So, I think that fine_gravel, salt and ice should still be “paved”.
> 
> Nuno Pedrosa.
> 
> PS: Sorry to “butt in” the talk. I’m usually silent in this list, though I 
> read most of the discussions. Your work is amazing and I find that I can add 
> little to what is being discussed, so I try to keep my “noise” to a minimum!
> 
> 
> On 7 Feb 2017, at 09:40, lig fietser 
>  
> > wrote:
> 
> I'd call that semi-paved but Garmin doesn't have such category unfortunately. 
> Since the default style main focus is on motor vehicles I'd suggest to add 
> surfaces like fine_gravel, salt, ice to the unpaved list. And please add soil 
> to it, it seems a quite popular tag.
> 
> 
> 

Re: [mkgmap-dev] To do: If-Then-Else

[Dave Swarthout]

It would be easier for the parser without curly braces:
+1

I was gonna suggest not using curly-braces earlier but don't know enough
about parsers to make such a request. Seeing as they're already required in
other places, it would be advantageous to not require them again in this
context.

Dave

On Wed, Feb 8, 2017 at 6:28 PM, Steve Ratcliffe 
wrote:

>
> Hi
>
> don't know if this helps:
>> I see one possible implementation for a conditional rule like
>> if () {
>>  some rules
>> } else {
>> other rules
>> }
>> where  would be something like tag=val, maybe also a parameter given
>> to the program.
>> If someone knows how to implement the syntax parser for such an
>> if-thent-else clause the evaluation could simply
>>
>
> It would be easier for the parser without curly braces:
>
> if (  some rules
> else
>  other rules
> endif
>
> I could make that work.
>
> ..Steve
>
> translate the if () to a rule like
>> exp {set special_var_x=true;}
>> and then add this special tag with tag=true or tag!=true to each
>> conditional rule.
>> So, we would not  need many changes in the evaluation of the rules, only
>> in the parser.
>>
>> Gerd
>>
>> 
>> Von: mkgmap-dev  im Auftrag von
>> Mike Baggaley 
>> Gesendet: Dienstag, 7. Februar 2017 18:22:32
>> An: mkgmap-dev@lists.mkgmap.org.uk
>> Betreff: Re: [mkgmap-dev] To do: If-Then-Else
>>
>> Hi Andrzej, can you not make use of mkgmap:country to handle this
>> scenario?
>>
>> mkgmap:country=DZA | mkgmap:country=AGO |  mkgmap:country=SHN |
>> mkgmap:country=BEN ... {set continent=AF}
>>
>> continent=AF & landuse=farmland [0x10f01 level 1]
>>
>> Would mkgmap be better with a mkgmap:continent variable using
>> place=continent added?
>>
>> Regards,
>> Mike
>>
>> -Original Message-
>> From: Andrzej Popowski [mailto:po...@poczta.onet.pl]
>> Sent: 07 February 2017 12:39
>> To: mkgmap-dev@lists.mkgmap.org.uk
>> Subject: Re: [mkgmap-dev] To do: If-Then-Else
>>
>> Hi Dave,
>>
>> I think the idea is to include some preprocessing capability to style
>> interpreter.
>>
>> I develop a single style for my topo maps, but I need some possibility
>> to get a small variation in style depending on region. For example I
>> prefer to show landuse=farmland on a map of Africa but to remove it on a
>> map of Europe. So instead of maintaining 2 nearly identical styles, I
>> would like to get a conditional statement, something like:
>>
>> if (SHOW_FARMS) (
>> landuse=farmland [0x10f01 level 1]
>> )
>>
>> and then add (or not) an option to mkgmap like --style-define=SHOW_FARMS
>>
>> --
>> Best regards,
>> Andrzej
>>
>>
>> ___
>> 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
>



-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] unpaved roads

[Carlos Dávila]

I don't see the point of that example. It's a place in the countryside, 
so people going there is probably aware they may need to travel over a 
track. Anyway, there's a paved road that leads you only 220 m away from 
Las Lomas, so you'll probably be able to reach the place even if unpaved 
roads are disabled in the GPS. I'm sorry, but I don't see the need to 
mark unpaved ways as paved.


El 08/02/17 a las 12:27, Nuno Pedrosa escribió:
Ok. But that will mean that in a generic map, a lot of places will be 
unroutable if the GPS is avoiding all unpaved roads. To reach them, 
the user will need to allow unpaved roads in the route. This will mean 
routing through sand roads and gravel roads alike.
It would be great if the GPS could handle semi-paved roads, as was 
mentioned, but it can't.


In a generic map, what will be most important? To reach the 
destination, or to avoid getting dirt in the car?
In Cadiz, Finca Las Lomas, s/n, 11179 Vejer de la Frontera, Cádiz, 
Spain, would be mostly unreachable if avoiding gravel roads.
https://www.google.pt/maps/place/Escuelas+Profesionales+de+la+Sagrada+Familia+Nuestra+Señora+del+Buen+Consejo+de+las+Lomas/@36.2938403,-5.8821947,17z/data=!3m1!4b1!4m5!3m4!1s0xd0c5074acf746b9:0x32a4ea0ba5f0c3d!8m2!3d36.293836!4d-5.880006 


There are lots of places like this.

A side-thought: paved roads aren’t always the best option for a given 
region. They are more expensive to build and when they degrade, they 
get “hard holes”(*) and fixing them up will usually create bumps in 
every hole. If the traffic is low, gravel roads will probably be a 
better option and better yet if rain is uncommon, as is the case in 
southern Europe.


Nuno Pedrosa

(*) by “hard holes”, I mean pot-holes where the edges are very steep 
and the wheels will crash into it. Gravel roads tend to create 
pot-holes with soft edges, a lot easier to drive over.




On 7 Feb 2017, at 11:39, Carlos Dávila > wrote:


I don't agree with you. I think default style is a generic style, and 
as such, it shouldn't do much guess but use the strict meaning of 
tags. Gravel, fine_gravel, ice, etc. are strictly unpaved and I would 
mark them as such in default style. More specific uses (mtb/race 
bicycle/4wd...) require specific maps and thus specific styles.
@Mark: I'm also cyclist and for mtb use your "raining" point of view 
of paved/unpaved is important to be considered.


El 07/02/17 a las 11:57, Nuno Pedrosa escribió:
Hi! In Portugal, Spain and surely a little all around, unpaved 
gravel roads are common, even on urban neighbourhoods.
These are quite drivable and they will often be the only way to get 
to some places. They are also suitable to all vehicles, even if they 
will get covered in dirt.
There are also a lot of paths going through sand (forest roads) and 
these will unsuitable to most vehicles (even a lot of 4x4s), 
regardless of their width.


I find that while driving, the real issue will be the road 
conditions and width. Will the unpaved road be wide enough for a car 
or light truck? Will it have deep tracks due to soil erosion? Will 
the surface be solid enough to drive in a regular car?


So, in real world GPS usage, I would like unpaved to mean “narrow, 
earth roads”, while paved would mean any road suitable to all 
regular vehicles.
Example: due to wind farms being built in a lot of hill ranges, 
large, unpaved roads were built. These are gravel, wide roads, and 
often are a better option to the paved, sinuous mountain roads that 
go around every nook and cranny in the valleys.


So, I think that fine_gravel, salt and ice should still be “paved”.

Nuno Pedrosa.

PS: Sorry to “butt in” the talk. I’m usually silent in this list, 
though I read most of the discussions. Your work is amazing and I 
find that I can add little to what is being discussed, so I try to 
keep my “noise” to a minimum!



On 7 Feb 2017, at 09:40, lig fietser > wrote:


I'd call that semi-paved but Garmin doesn't have such category 
unfortunately. Since the default style main focus is on motor 
vehicles I'd suggest to add surfaces like fine_gravel, salt, ice to 
the unpaved list. And please add soil to it, it seems a quite 
popular tag.



Gerd wrote
This "raining" part is probably what paved/unpaved is about: The 
surface of a paved road should not change when it's raining
and your vehicle will not be covered with dirt when traveling on a 
paved road while it is raining (at least not from dirt which was 
part of the surface).


Do you agree on that (last 

Re: [mkgmap-dev] unpaved roads

[Gerd Petermann]

Hu Nuna,

If I got that right the Garmin algo uses unpaved roads if the target is only 
reachable via unpaved
roads, at least if the target itself is an unpaved road.

Gerd

Von: mkgmap-dev  im Auftrag von Nuno 
Pedrosa 
Gesendet: Mittwoch, 8. Februar 2017 12:27:11
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] unpaved roads

Ok. But that will mean that in a generic map, a lot of places will be 
unroutable if the GPS is avoiding all unpaved roads. To reach them, the user 
will need to allow unpaved roads in the route. This will mean routing through 
sand roads and gravel roads alike.
It would be great if the GPS could handle semi-paved roads, as was mentioned, 
but it can't.

In a generic map, what will be most important? To reach the destination, or to 
avoid getting dirt in the car?
In Cadiz, Finca Las Lomas, s/n, 11179 Vejer de la Frontera, Cádiz, Spain, would 
be mostly unreachable if avoiding gravel roads.
https://www.google.pt/maps/place/Escuelas+Profesionales+de+la+Sagrada+Familia+Nuestra+Señora+del+Buen+Consejo+de+las+Lomas/@36.2938403,-5.8821947,17z/data=!3m1!4b1!4m5!3m4!1s0xd0c5074acf746b9:0x32a4ea0ba5f0c3d!8m2!3d36.293836!4d-5.880006
There are lots of places like this.

A side-thought: paved roads aren’t always the best option for a given region. 
They are more expensive to build and when they degrade, they get “hard 
holes”(*) and fixing them up will usually create bumps in every hole. If the 
traffic is low, gravel roads will probably be a better option and better yet if 
rain is uncommon, as is the case in southern Europe.

Nuno Pedrosa

(*) by “hard holes”, I mean pot-holes where the edges are very steep and the 
wheels will crash into it. Gravel roads tend to create pot-holes with soft 
edges, a lot easier to drive over.



On 7 Feb 2017, at 11:39, Carlos Dávila 
> wrote:

I don't agree with you. I think default style is a generic style, and as such, 
it shouldn't do much guess but use the strict meaning of tags. Gravel, 
fine_gravel, ice, etc. are strictly unpaved and I would mark them as such in 
default style. More specific uses (mtb/race bicycle/4wd...) require specific 
maps and thus specific styles.
@Mark: I'm also cyclist and for mtb use your "raining" point of view of 
paved/unpaved is important to be considered.

El 07/02/17 a las 11:57, Nuno Pedrosa escribió:
Hi! In Portugal, Spain and surely a little all around, unpaved gravel roads are 
common, even on urban neighbourhoods.
These are quite drivable and they will often be the only way to get to some 
places. They are also suitable to all vehicles, even if they will get covered 
in dirt.
There are also a lot of paths going through sand (forest roads) and these will 
unsuitable to most vehicles (even a lot of 4x4s), regardless of their width.

I find that while driving, the real issue will be the road conditions and 
width. Will the unpaved road be wide enough for a car or light truck? Will it 
have deep tracks due to soil erosion? Will the surface be solid enough to drive 
in a regular car?

So, in real world GPS usage, I would like unpaved to mean “narrow, earth 
roads”, while paved would mean any road suitable to all regular vehicles.
Example: due to wind farms being built in a lot of hill ranges, large, unpaved 
roads were built. These are gravel, wide roads, and often are a better option 
to the paved, sinuous mountain roads that go around every nook and cranny in 
the valleys.

So, I think that fine_gravel, salt and ice should still be “paved”.

Nuno Pedrosa.

PS: Sorry to “butt in” the talk. I’m usually silent in this list, though I read 
most of the discussions. Your work is amazing and I find that I can add little 
to what is being discussed, so I try to keep my “noise” to a minimum!


On 7 Feb 2017, at 09:40, lig fietser 
 
> wrote:

I'd call that semi-paved but Garmin doesn't have such category unfortunately. 
Since the default style main focus is on motor vehicles I'd suggest to add 
surfaces like fine_gravel, salt, ice to the unpaved list. And please add soil 
to it, it seems a quite popular tag.


Gerd wrote
This "raining" part is probably what paved/unpaved is about: The surface of a 
paved road should not change when it's raining
and your vehicle will not be covered with dirt when traveling on a paved road 
while it is raining (at least not from dirt which was part of the surface).

Do you agree on that (last sentence)?

Gerd

Re: [mkgmap-dev] unpaved roads

[Gerd Petermann]

ligfietser wrote
> I suppose you first look if surface=* ? And what if surface is empty?

Good point.
My understanding is that most road types are paved unless stated otherwise.
Exception: hw=track, bridleway, unsurfaced, maybe also path, although I
don't
like that one.

Gerd






--
View this message in context: 
http://gis.19327.n8.nabble.com/unpaved-roads-tp5890722p5890863.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] To do: If-Then-Else

[Steve Ratcliffe]

Hi


don't know if this helps:
I see one possible implementation for a conditional rule like
if () {
 some rules
} else {
other rules
}
where  would be something like tag=val, maybe also a parameter given to 
the program.
If someone knows how to implement the syntax parser for such an if-thent-else 
clause the evaluation could simply


It would be easier for the parser without curly braces:

if ( im Auftrag von Mike Baggaley 

Gesendet: Dienstag, 7. Februar 2017 18:22:32
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] To do: If-Then-Else

Hi Andrzej, can you not make use of mkgmap:country to handle this scenario?

mkgmap:country=DZA | mkgmap:country=AGO |  mkgmap:country=SHN |
mkgmap:country=BEN ... {set continent=AF}

continent=AF & landuse=farmland [0x10f01 level 1]

Would mkgmap be better with a mkgmap:continent variable using
place=continent added?

Regards,
Mike

-Original Message-
From: Andrzej Popowski [mailto:po...@poczta.onet.pl]
Sent: 07 February 2017 12:39
To: mkgmap-dev@lists.mkgmap.org.uk
Subject: Re: [mkgmap-dev] To do: If-Then-Else

Hi Dave,

I think the idea is to include some preprocessing capability to style
interpreter.

I develop a single style for my topo maps, but I need some possibility
to get a small variation in style depending on region. For example I
prefer to show landuse=farmland on a map of Africa but to remove it on a
map of Europe. So instead of maintaining 2 nearly identical styles, I
would like to get a conditional statement, something like:

if (SHOW_FARMS) (
landuse=farmland [0x10f01 level 1]
)

and then add (or not) an option to mkgmap like --style-define=SHOW_FARMS

--
Best regards,
Andrzej


___
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] unpaved roads

[Nuno Pedrosa]

Ok. But that will mean that in a generic map, a lot of places will be 
unroutable if the GPS is avoiding all unpaved roads. To reach them, the user 
will need to allow unpaved roads in the route. This will mean routing through 
sand roads and gravel roads alike.
It would be great if the GPS could handle semi-paved roads, as was mentioned, 
but it can't.

In a generic map, what will be most important? To reach the destination, or to 
avoid getting dirt in the car?
In Cadiz, Finca Las Lomas, s/n, 11179 Vejer de la Frontera, Cádiz, Spain, would 
be mostly unreachable if avoiding gravel roads.
https://www.google.pt/maps/place/Escuelas+Profesionales+de+la+Sagrada+Familia+Nuestra+Señora+del+Buen+Consejo+de+las+Lomas/@36.2938403,-5.8821947,17z/data=!3m1!4b1!4m5!3m4!1s0xd0c5074acf746b9:0x32a4ea0ba5f0c3d!8m2!3d36.293836!4d-5.880006
 

There are lots of places like this.

A side-thought: paved roads aren’t always the best option for a given region. 
They are more expensive to build and when they degrade, they get “hard 
holes”(*) and fixing them up will usually create bumps in every hole. If the 
traffic is low, gravel roads will probably be a better option and better yet if 
rain is uncommon, as is the case in southern Europe.

Nuno Pedrosa

(*) by “hard holes”, I mean pot-holes where the edges are very steep and the 
wheels will crash into it. Gravel roads tend to create pot-holes with soft 
edges, a lot easier to drive over.



> On 7 Feb 2017, at 11:39, Carlos Dávila  wrote:
> 
> I don't agree with you. I think default style is a generic style, and as 
> such, it shouldn't do much guess but use the strict meaning of tags. Gravel, 
> fine_gravel, ice, etc. are strictly unpaved and I would mark them as such in 
> default style. More specific uses (mtb/race bicycle/4wd...) require specific 
> maps and thus specific styles.
> @Mark: I'm also cyclist and for mtb use your "raining" point of view of 
> paved/unpaved is important to be considered.
> 
> El 07/02/17 a las 11:57, Nuno Pedrosa escribió:
>> Hi! In Portugal, Spain and surely a little all around, unpaved gravel roads 
>> are common, even on urban neighbourhoods.
>> These are quite drivable and they will often be the only way to get to some 
>> places. They are also suitable to all vehicles, even if they will get 
>> covered in dirt.
>> There are also a lot of paths going through sand (forest roads) and these 
>> will unsuitable to most vehicles (even a lot of 4x4s), regardless of their 
>> width.
>> 
>> I find that while driving, the real issue will be the road conditions and 
>> width. Will the unpaved road be wide enough for a car or light truck? Will 
>> it have deep tracks due to soil erosion? Will the surface be solid enough to 
>> drive in a regular car?
>> 
>> So, in real world GPS usage, I would like unpaved to mean “narrow, earth 
>> roads”, while paved would mean any road suitable to all regular vehicles.
>> Example: due to wind farms being built in a lot of hill ranges, large, 
>> unpaved roads were built. These are gravel, wide roads, and often are a 
>> better option to the paved, sinuous mountain roads that go around every nook 
>> and cranny in the valleys.
>> 
>> So, I think that fine_gravel, salt and ice should still be “paved”.
>> 
>> Nuno Pedrosa.
>> 
>> PS: Sorry to “butt in” the talk. I’m usually silent in this list, though I 
>> read most of the discussions. Your work is amazing and I find that I can add 
>> little to what is being discussed, so I try to keep my “noise” to a minimum!
>> 
>> 
>>> On 7 Feb 2017, at 09:40, lig fietser >>  >> >> wrote:
>>> 
>>> I'd call that semi-paved but Garmin doesn't have such category 
>>> unfortunately. Since the default style main focus is on motor vehicles I'd 
>>> suggest to add surfaces like fine_gravel, salt, ice to the unpaved list. 
>>> And please add soil to it, it seems a quite popular tag.
>>> 
>>> 
>>> Gerd wrote
>>> This "raining" part is probably what paved/unpaved is about: The surface of 
>>> a paved road should not change when it's raining
>>> and your vehicle will not be covered with dirt when traveling on a paved 
>>> road while it is raining (at least not from dirt which was part of the 
>>> surface).
>>> 
>>> Do you agree on that (last sentence)?
>>> 
>>> Gerd
> 
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk

Re: [mkgmap-dev] Problems with -- gmapi (and possibly --gmapsupp also)

[Steve Ratcliffe]

Hi Patrik


Folder structure looks the same as with for example jmc_cli.


I'm sorry but I still do not understand the problem.

If you create a map normally and then convert it with the garmin
converter does that gmapi map work?

The same map converted with mkgmap --gmapi, you are saying does
not work.

So if the first one works, but the second doesn't, then there must be
a difference between the two maps.

The only differences I know of are:

1. We do not create the top level osmmap.gmapi directory.
2. There are differences in the white space in the Info.xml file.

Or there is a difference in your case that I am not aware of.

If the problem is the first, then it is easy enough to fix.
I can't believe that it is the second, but you never know..

If there is another difference I need to know what it is.
If you could create a small map that does not work that you
could upload that would be helpful.

..Steve


It doesn't make a difference if I call mkgmap --gmapsupp with the
overview parameters (--overview-mapname=... --overview-mapnumber=...),
in no case I have overview maps.
The only difference is how the files are named inside the gmap directory
structure, either with the choosen names or with the default names.

Below shown call of mkgmap is the version without overview options...

Cheers
Patrik

On 06.02.2017 23:33, Steve Ratcliffe wrote:

Hi Patrik


I've just noticed that the quite new option --gmapi does not work
properly regarding overview maps:
- I first build the img files where all is correct, overview maps are
properly built and set at the different needed locations (*.tdb file,
elsewhere ?)
- running mkgmap with the option --gmapi (complete output shown below)
causes that the overview maps are not anymore shown in BaseCamp


How does the gmapi map differ from one created using the script or
Garmin's conversion tool?



BTW: Something similar happens probably with --gmapsupp: there are now
overview maps visible on the GPS itself.


The gmapsupp does not contain a base map.  I suppose if you actually
included it on the command line then it would be added, but you should
not do that.

..Steve

Here the call of mkgmap and its output:

java -Xmx1536M -Dfile.encoding=UTF-8 -jar
D:/fzk/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/tools/mkgmap/mkgmap.jar
--max-jobs=2 --index --code-page=1252 --gmapi
--license-file=Freizeitkarte_LUX.license --product-id=1
--family-id=6442 --family-name="Freizeitkarte_LUX"
--series-name="Freizeitkarte_LUX" --description="Freizeitkarte_LUX
(Release 17.02)" --product-version="6442" 6442*.img 6442.TYP
--tdbfile --show-profiles=1
Time started: Sun Feb 05 16:10:10 CET 2017
Number of MapFailedExceptions: 0
Number of ExitExceptions: 0
Time finished: Sun Feb 05 16:10:12 CET 2017
Total time taken: 1858ms

Am I doing something wrong or is this a 'defect' in the newly
implemented gmapi option ?

Thanks for helping
Patrik


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



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


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


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

Re: [mkgmap-dev] is_in filter

[Felix Hartmann]

On 7 February 2017 at 23:52, Andrzej Popowski  wrote:

> I like your ideas about is_in and urban areas. But I have doubts about
> practical results. IMO areas like landuse=residential or place=city/town
> aren't mapped well in OSM data. So even if you add some new features to
> mkgmap, it won't be useful, because input data is not precise.
>
> Some consideration about urban area. I think using buildings or house
> numbers as indication of urban area won't be reliable. Mostly because these
> are data from imports, so some cities get them while others still do
> without. Probably highway's junctions (crossroads) could be the best
> indication of urban area. Roads are usually mapped correctly and number of
> junctions shows complexity of road network.
>

You have a good point there - I also think residential and city/town are
not that well mapped. Housenumbers are pretty well mapped in many european
countries though - but not in the rest of the world. Buildings I would
guess are sufficiently mapped in most european countries in OSM.
Road junctions have one problem - actually residential areas (as in where
people are living) have most junctions, while city centers / commercial
areas feature much bigger buildings and less intersections.  Maybe the kind
of roads in such areas would help to better identify them. Urban areas
would be easy to find however - take the amount of crossings from
highway=track/path/cycleway vs
highway=residential/primary-secondary-tertiary-unclassified and the picture
should be very clear.

I think both methods will allow for an improvement in routing as well as an
improvement to exclude clutter from buildings in maps if we can derive a
classification level of urbanisation from it and feed it to mkgmap like
bounds and sea files.
My idea would be there should be an analysis of 400x400m patches - then
join them and find out how big the area becomes - any areas that have more
than 3-4 connected patches can then be classified as urban in the
"urban_bounds" file - if it's one or two of such patches - I'ld rather keep
the buildings in my maps and also still consider it rural (because for a
tiny mountain village - I'ld like to keep them - however for a mountain
town like Zermatt, Ischgl or their like - I'ld prefer to remove them -
while for big cities is essential to remove the buildings.


-- 
Felix Hartman - Openmtbmap.org & VeloMap.org
Schusterbergweg 32/8
6020 Innsbruck
Austria - Österreich
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] unpaved roads

[lig fietser]

Gerd, 
I suppose you first look if surface=* ? And what if surface is empty?



Gerd wrote:

Anyhow, my impression is that it would be better to change the rule so that it 
checks the known
paved surfaces and assumes that all others mean unpaved.
The current rules are quite old, it was introduced with r1425 and last changed 
with r1489.

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

[mkgmap-dev] unit test fails in branch

[Gerd Petermann]

Hi Ticker,

please check:
The unit test testCombiningSupps() in class GmapsuppTest fails:
SCHWERWIEGEND (MapFailedException): (thrown in Area.split()) Area split shift 
align problems
uk.me.parabola.imgfmt.MapFailedException: Area split shift align problems
at uk.me.parabola.imgfmt.app.Area.split(Area.java:174)
at uk.me.parabola.mkgmap.build.MapArea.split(MapArea.java:206)
at 
uk.me.parabola.mkgmap.build.MapSplitter.splitMaxSize(MapSplitter.java:234)
at uk.me.parabola.mkgmap.build.MapSplitter.split(MapSplitter.java:103)
at 
uk.me.parabola.mkgmap.build.MapBuilder.makeMapAreas(MapBuilder.java:698)
at uk.me.parabola.mkgmap.build.MapBuilder.makeMap(MapBuilder.java:234)
at 
uk.me.parabola.mkgmap.combiners.OverviewBuilder.writeOverviewMap(OverviewBuilder.java:184)
at 
uk.me.parabola.mkgmap.combiners.OverviewBuilder.onFinish(OverviewBuilder.java:91)
at uk.me.parabola.mkgmap.main.Main.endOptions(Main.java:620)
at 
uk.me.parabola.mkgmap.CommandArgsReader.readArgs(CommandArgsReader.java:128)
at uk.me.parabola.mkgmap.main.Main.mainStart(Main.java:138)
at uk.me.parabola.mkgmap.main.Main.mainNoSystemExit(Main.java:105)
at func.files.GmapsuppTest.testCombiningSupps(GmapsuppTest.java:129)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at 
org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
at 
org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at 
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
at 
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:678)
at 
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
at 
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
Number of ExitExceptions: 1
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev