Re: [mkgmap-dev] 3746 mkgmap

[Steve Sgalowski]

Gerd on this matter , i can only test if it changes when i drive that route
..

Driving the route today ..
Stephen


On 11 Jan 2017 3:16 PM, "Gerd Petermann" 
wrote:

> Hi Steve,
>
> sorry, I have no idea what that means.
> Please describe start and end point of the route and where map from r3746
> is worse compared to the older release and what older release.
>
> Gerd
>
> 
> Von: mkgmap-dev  im Auftrag von
> Steve Sgalowski 
> Gesendet: Mittwoch, 11. Januar 2017 00:43:51
> An: Development list for mkgmap
> Betreff: [mkgmap-dev] 3746 mkgmap
>
> with this patch there is a problem with routing in australia / queensland
>
> not shure if isolated or not , but when I live on moggill rd Pinjarra
> hills , and there is Pinjarra road behind me jus 400 m  through the bush ,
> it does not ever come off , the  preferrd route , to the route you are
> driving .
>
> 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] Commit r3743: Reduce rounding error when saving initial heading in compacted format

[Andrzej Popowski]

Hi,

I have tested last problem with mkgmap r3742M, which should disable 
compacted format of angles. It works better but not ideally. r3743 gives 
3 times "turn left", when actually route leads straight ahead. Patched 
r3742M gives one "bear left" and one "turn left".


I have an older map, which works perfectly for this route. I have 
checked, that release r3742 is good too. It looks like precise angles 
aren't calculated or used correctly.


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

Re: [mkgmap-dev] type=through_route relations and mkgmap r3743

[Carlos Dávila]

El 11/01/17 a las 20:36, Andrzej Popowski escribió:

Hi Carlos,

so you expect, that following "through_route", shouldn't generate 
navigation message? This is a bit different, then I assumed. My first 
idea was to make as many messages as possible, when crossroad include 
any "through_route".


For Y shaped crossroads, we can simulate angle 180 for "through_route" 
and 90 for second one. I think result would depend on roads types and 
on whether roads have names.




Yes, that was the original purpose of through_route, if I recall correctly.


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

Re: [mkgmap-dev] How to label maps generated by mkgmap -r3742

[Andrzej Popowski]

Hi,

there is command line version of GMapTool too. You can run it in a batch 
like this:

>gmt.exe -w -c 1.02 gmapsupp.img

Map version is in bytes 8-9 of the header. Support in mkgmap could be 
added as easy as option --hide-gmapsupp-on-pc. Only pitfall is 
processing values like 1.1, which can mean 1.10 or 1.01.


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

Re: [mkgmap-dev] type=through_route relations and mkgmap r3743

[Andrzej Popowski]

Hi Carlos,

so you expect, that following "through_route", shouldn't generate 
navigation message? This is a bit different, then I assumed. My first 
idea was to make as many messages as possible, when crossroad include 
any "through_route".


For Y shaped crossroads, we can simulate angle 180 for "through_route" 
and 90 for second one. I think result would depend on roads types and on 
whether roads have names.


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

Re: [mkgmap-dev] type=through_route relations and mkgmap r3743

[Carlos Dávila]

I have fixed OSM data and still get "Turn left onto Calle Botánico Rivas 
Mateos", so it seems through_route relation is steel needed and should 
be parsed.


El 11/01/17 a las 18:48, Gerd Petermann escribió:

Hi Carlos,

thanks, I've got the test case on my disk, you can correct the OSM data.

Gerd

Von: mkgmap-dev  im Auftrag von Carlos Dávila 

Gesendet: Mittwoch, 11. Januar 2017 18:41:45
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] type=through_route relations and mkgmap r3743

Yes, that's the intended effect. But that particular relation could be
removed, because there are some wrong tagging here. Second part of Calle
José Luis Cotallo should be tagged as service, with no name. I'll change
it, but if you want to use it as test case I can wait for the commit.

El 10/01/17 a las 09:31, Gerd Petermann escribió:

I found one that might be interesting:
https://www.openstreetmap.org/relation/406379

If I got that right the intention was to tell mkgmap that
it should change the bearing (heading) values in the map so that the Garmin
algo doesn't produce a
hint like "Turn left onto Calle Botánico Rivas Mateos" when travelling from
way 24647941 (Calle José Luis Cotallo) to way 24311294 (Calle Botánico Rivas
Mateos).
(this is what happens now)

What would you want instead?
@Carlos: You have created that relation in 2010, maybe you remember?

Gerd




Gerd Petermann wrote

Hi all,

I've noticed that mkgmap still checks these relations for correctness but
they have no influence on the created map.
Part of the code that handled them was removed with r3649:
http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap=3649

If your map was created with r3743 or later, please check if you find a
crossing with such a relation which where routing
hints are wrong. In that case I would try to add code for the support,
else some unused code can be removed.

Gerd




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

Re: [mkgmap-dev] Commit r3743: Reduce rounding error when saving initial heading in compacted format

[Gerd Petermann]

Hi Carlos,

okay, I'll try to reproduce and find a reason for that tomorrow.

Gerd


Von: mkgmap-dev  im Auftrag von Carlos 
Dávila 
Gesendet: Mittwoch, 11. Januar 2017 18:20:49
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Commit r3743: Reduce rounding error when saving 
initial heading in compacted format

I'm sorry for the late replay. As for Andrzej, it fixed routing
problems. Another issue arose though: I get some weird "turn left"
instructions in places where you just have to go straight ahead, such as
the followings (traveling from West to East along AV-102). r3742 doesn't
give turn instructions on that places.
http://www.openstreetmap.org/#map=19/40.48509/-5.44977=H
http://www.openstreetmap.org/#map=18/40.47347/-5.37196=H
http://www.openstreetmap.org/#map=18/40.47393/-5.36321=H

El 08/01/17 a las 15:17, Gerd Petermann escribió:
> Hi all,
>
> r3743 should fix some of the routing errors reported by Carlos and Andrzej.
> The old code always rounded down when saving the heading in the compacted 
> format, so that e.g.
> 0x2f was rounded to 0x20  instead of 0x30. The compacted format saves only 
> the topmost 4 bits.
>
> @Carlos, Andrzej: Please can you verify that this also solves the problem.
>
> Gerd
>
>
> 
> Von: mkgmap-dev  im Auftrag von svn 
> commit 
> Gesendet: Sonntag, 8. Januar 2017 15:08:40
> An: mkgmap-...@lists.mkgmap.org.uk; mkgmap-dev@lists.mkgmap.org.uk
> Betreff: [mkgmap-dev] Commit r3743: Reduce rounding error when saving initial 
> heading in compacted format
>
> Version mkgmap-r3743 was committed by gerd on Sun, 08 Jan 2017
>
> Reduce rounding error when saving initial heading in compacted format
>
> http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap=3743
> ___

___
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] type=through_route relations and mkgmap r3743

[Gerd Petermann]

Hi Carlos,

thanks, I've got the test case on my disk, you can correct the OSM data.

Gerd

Von: mkgmap-dev  im Auftrag von Carlos 
Dávila 
Gesendet: Mittwoch, 11. Januar 2017 18:41:45
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] type=through_route relations and mkgmap r3743

Yes, that's the intended effect. But that particular relation could be
removed, because there are some wrong tagging here. Second part of Calle
José Luis Cotallo should be tagged as service, with no name. I'll change
it, but if you want to use it as test case I can wait for the commit.

El 10/01/17 a las 09:31, Gerd Petermann escribió:
> I found one that might be interesting:
> https://www.openstreetmap.org/relation/406379
>
> If I got that right the intention was to tell mkgmap that
> it should change the bearing (heading) values in the map so that the Garmin
> algo doesn't produce a
> hint like "Turn left onto Calle Botánico Rivas Mateos" when travelling from
> way 24647941 (Calle José Luis Cotallo) to way 24311294 (Calle Botánico Rivas
> Mateos).
> (this is what happens now)
>
> What would you want instead?
> @Carlos: You have created that relation in 2010, maybe you remember?
>
> Gerd
>
>
>
>
> Gerd Petermann wrote
>> Hi all,
>>
>> I've noticed that mkgmap still checks these relations for correctness but
>> they have no influence on the created map.
>> Part of the code that handled them was removed with r3649:
>> http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap=3649
>>
>> If your map was created with r3743 or later, please check if you find a
>> crossing with such a relation which where routing
>> hints are wrong. In that case I would try to add code for the support,
>> else some unused code can be removed.
>>
>> Gerd

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

Re: [mkgmap-dev] type=through_route relations and mkgmap r3743

[Carlos Dávila]

Yes, that's the intended effect. But that particular relation could be 
removed, because there are some wrong tagging here. Second part of Calle 
José Luis Cotallo should be tagged as service, with no name. I'll change 
it, but if you want to use it as test case I can wait for the commit.


El 10/01/17 a las 09:31, Gerd Petermann escribió:

I found one that might be interesting:
https://www.openstreetmap.org/relation/406379

If I got that right the intention was to tell mkgmap that
it should change the bearing (heading) values in the map so that the Garmin
algo doesn't produce a
hint like "Turn left onto Calle Botánico Rivas Mateos" when travelling from
way 24647941 (Calle José Luis Cotallo) to way 24311294 (Calle Botánico Rivas
Mateos).
(this is what happens now)

What would you want instead?
@Carlos: You have created that relation in 2010, maybe you remember?

Gerd




Gerd Petermann wrote

Hi all,

I've noticed that mkgmap still checks these relations for correctness but
they have no influence on the created map.
Part of the code that handled them was removed with r3649:
http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap=3649

If your map was created with r3743 or later, please check if you find a
crossing with such a relation which where routing
hints are wrong. In that case I would try to add code for the support,
else some unused code can be removed.

Gerd


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

[mkgmap-dev] Splitter r570

[Gerd Petermann]

Hi all,

I've merged the junit branch and the memory_opt2 branch into trunk.

There are no changes in the user interface. The unit test framework was changed 
to junit (as with mkgmap),
but this is only important for developers of splitter.
A new ant target run.func-tests performs some functional tests. I'll add more 
in the next days.

The major improvements from the memory_opt2 branch:
- a smaller memory footprint, esp. when splitting large files like europe or 
planet with a rather small --max-nodes value
- still you'll see thesame or slightly better throughput compared to r560

Some numbers;

Split planet with --max-nodes=100

The stats after Problem-list-generator :

r560:

coord Map: 3.670.470.372 stored long/int pairs require ca. 1.0 bytes per pair. 
67931848 chunks are used, the avg. number of values in one 64-chunk is 54.
coord Map details: bytes ~3.523 MB, including 35 array(s) with 8 MB

way Map: 385.087.014 stored long/int pairs require ca. 1.15 bytes per pair. 
7019031 chunks are used, the avg. number of values in one 64-chunk is 54.
way Map details: bytes ~423 MB, including 4 array(s) with 8 MB

Problem-list-generator pass(es) took 879042 ms


r:570:
coord Map: 3.670.470.372 stored long/int pairs require ca. 0.48 bytes per pair. 
67931848 chunks are used, the avg. number of values in one 64-chunk is 54.
coord Map details: bytes ~1.710 MB, including 35 array(s) with 8 MB

way Map: 385.087.014 stored long/int pairs require ca. 0.75 bytes per pair. 
7019031 chunks are used, the avg. number of values in one 64-chunk is 54.
way Map details: bytes ~276 MB, including 4 array(s) with 8 MB

...

Problem-list-generator pass(es) took 829059 ms

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

Re: [mkgmap-dev] Commit r3743: Reduce rounding error when saving initial heading in compacted format

[Carlos Dávila]

I'm sorry for the late replay. As for Andrzej, it fixed routing 
problems. Another issue arose though: I get some weird "turn left" 
instructions in places where you just have to go straight ahead, such as 
the followings (traveling from West to East along AV-102). r3742 doesn't 
give turn instructions on that places.

http://www.openstreetmap.org/#map=19/40.48509/-5.44977=H
http://www.openstreetmap.org/#map=18/40.47347/-5.37196=H
http://www.openstreetmap.org/#map=18/40.47393/-5.36321=H

El 08/01/17 a las 15:17, Gerd Petermann escribió:

Hi all,

r3743 should fix some of the routing errors reported by Carlos and Andrzej.
The old code always rounded down when saving the heading in the compacted 
format, so that e.g.
0x2f was rounded to 0x20  instead of 0x30. The compacted format saves only the 
topmost 4 bits.

@Carlos, Andrzej: Please can you verify that this also solves the problem.

Gerd



Von: mkgmap-dev  im Auftrag von svn commit 

Gesendet: Sonntag, 8. Januar 2017 15:08:40
An: mkgmap-...@lists.mkgmap.org.uk; mkgmap-dev@lists.mkgmap.org.uk
Betreff: [mkgmap-dev] Commit r3743: Reduce rounding error when saving initial 
heading in compacted format

Version mkgmap-r3743 was committed by gerd on Sun, 08 Jan 2017

Reduce rounding error when saving initial heading in compacted format

http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap=3743
___


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

Re: [mkgmap-dev] How to label maps generated by mkgmap -r3742

[greg crago]

If you use SPLITTER before using mkgap, this command should put the version
# in same text as MAPNAME

java -ea -Xmx1024M -jar \MKGMAP\mkgmap-r3742\mkgmap-r3742\mkgmap.jar
--family-id=111 --family-name="xxx" --product-id=3 --series-name="yyy"
--area-name="My_maps" --x-mapset-name=zzz - --latin1 --index
--x-split-name-index --bounds=\MKGMAP\bounds.zip
--location-autofill=bounds,is_in,nearest --housenumbers
--overview-mapname=WW-ov --overview-mapnumber=
--generate-sea=extend-sea-sectors,multipolygon,floodblocker,close-gaps=6000
--make-poi-index --process-destination --process-exits --tdbfile
--poi-address --verbose -c template.args master_thin.txt
--description="OPENSEAMAP version X" --gmapsupp

Look at --description option AFTER template.args

On Wed, Jan 11, 2017 at 7:04 AM, Andrzej Popowski 
wrote:

> Hi,
>
> I think this version comes from img header. You can set it with GMapTool,
> like in this example, only here fields for version are empty:
> http://www.gmaptool.eu/en/content/map-visible-basecamp
>
> --
> 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

Re: [mkgmap-dev] How to label maps generated by mkgmap -r3742

[Andrzej Popowski]

Hi,

I think this version comes from img header. You can set it with 
GMapTool, like in this example, only here fields for version are empty:

http://www.gmaptool.eu/en/content/map-visible-basecamp

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

Re: [mkgmap-dev] How to label maps generated by mkgmap -r3742

[rheinskipper1000]

Here is a screenshot how labels are displayed on my GPS:
https://1drv.ms/i/s!AtxQMXNLLc7Qjh829LBQubFgj3Q7

How can I set this map version number?



Von: Gerd Petermann
Gesendet: Dienstag, 10. Januar 2017 17:33
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] How to label maps generated by mkgmap -r3742


Hi Greg,

options.txt groups options by meaning. The order of options is important in 
that way that you can do something like this:
java -jar mkgmap.jar --style=s1 1234*.osm.pbf  --description=2nd_style 
--style=s2 1235*.osm.pbf
For the files 1234*.osm.pbf the style s1 is used and option  description is 
"not visible", for the files 1235*.osm.pbf the style s2 is used
and description is "2nd_style".
This concept is broken when it comes to options like "index","gmapsupp", 
"tdbfile", and others which are always processed after
the *.pbf files so that they always "see" the last setting of an option.
I hope that makes it clearer?

The file template.args is just a generated file which uses these rules, you can 
create your own file as well.
I'll think about a hint reg. template.args.

Gerd

Von: mkgmap-dev  im Auftrag von greg 
crago 
Gesendet: Dienstag, 10. Januar 2017 17:11:04
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] How to label maps generated by mkgmap -r3742

I want to make sure I understand how the ORDER of the OPTIONS are to used.
I was using the "options.txt" file to determine the order of the options. Is 
that correct?

Why exactly did you recommend putting the --description AFTER the -c 
template.args option?

Can you add a note to "options.txt" and using SPLTTER (template.args) 
OVERWRITES --mapname, --description, and --input-file?

I have --area-name and I cannot see it anywhere in BaseCamp or my GPS.
I used --x-mapeset-name=blabla and I cannot see it anywhere in BaseCamp or my 
GPS.

Greg

On Mon, Jan 9, 2017 at 10:49 PM, Gerd Petermann 
> wrote:
The java code shows that the options area-name and mapset-name are evaluated.
The latter one doesn't appear in the help file, so it is an undocumented
option and
you can only use it with --x-mapeset-name=blabla

GMapTool shows the value, but I did not try where it appears on the device
or what effect it has.

Gerd


greg crago wrote
> Thank you.
>
> java ... mkgmap.jar ... -c template.args master_thin.txt --description=XYZ
> --gmapsupp
>
> Worked on BaseCamp and on Garmin GPS.
>
> The only thing that would be nice would be a FAMILY description on the
> GPS.
> Right now, Garmin City Navigator Shows a MAPNAME and in a smaller font
> another name (family name?)





--
View this message in context: 
http://gis.19327.n8.nabble.com/How-to-label-maps-generated-by-mkgmap-r3742-tp597p5889072.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] New code for splitting polygon

[Ticker Berkin]

Hi Gerd

Here is a unit test for polygon splitting. To go in
{trunk}/test/uk/me/parabola/util/ShapeSplitterTest.java

Regards
Ticker

On Sun, 2017-01-08 at 10:30 +, Gerd Petermann wrote:
> Hi Ticker,
> 
> I think you can take the tests in uk.me.parabola.util  in mkgmap/test
> as an example.
> And sorry, I should already have coded one for
> clipSinglePathWithSutherlandHodgman().
> 
> Gerd
> 
> 
> 
> Von: mkgmap-dev  im Auftrag
> von Ticker Berkin 
> Gesendet: Sonntag, 8. Januar 2017 11:20:19
> An: mkgmap-dev@lists.mkgmap.org.uk
> Betreff: Re: [mkgmap-dev] New code for splitting polygon
> 
> Hi Gerd
> 
> Will do. Can you point me to an example of the preferred style for a
> unit test.
> 
> Thanks
> Ticker
> 
> On Sat, 2017-01-07 at 18:14 +, Gerd Petermann wrote:
> > Hi Ticker,
> > 
> > sounds great. Please can you add some unit tests to show what it
> > does
> > with holes, points on the split line
> > and one or more line segments  on the split line?
> > 
> > Gerd
> > 
> > Von: mkgmap-dev  im Auftrag
> > von Ticker Berkin 
> > Gesendet: Samstag, 7. Januar 2017 18:36:31
> > An: mkgmap development
> > Betreff: [mkgmap-dev] New code for splitting polygon
> > 
> > Hi Gerd
> > 
> > I've written some new code for splitting polygons in an efficient
> > manner. The main interface takes a shape and line of latitude or
> > longitude and returns 2 lists of shapes on either side of the line.
> > There is also a function to clip to rectangle.
> > 
> > I've put the code in util/ShapeSplitter but it could go elsewhere
> > if
> > you prefer.
> > 
> > So far I've only converted build/MapArea to use it, but I think it
> > can
> > be used throughout eventually. For the moment I've commented out
> > the
> > old code in MapArea, but this can be deleted in a while.
> > 
> > Regards
> > Ticker
> > ___
> > 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/*
 * Copyright (C) 2017.
 *
 * This program is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License version 3 or
 * version 2 as published by the Free Software Foundation.
 *
 * This program is distributed in the hope that it will be useful, but
 * WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
 * General Public License for more details.
 */
package uk.me.parabola.util;

import java.util.ArrayList;
//import java.util.Arrays;
import java.util.List;
import java.util.Collections;

import uk.me.parabola.util.Java2DConverter;
import uk.me.parabola.imgfmt.app.Area;
import uk.me.parabola.imgfmt.app.Coord;
import uk.me.parabola.mkgmap.filters.ShapeMergeFilter;
import uk.me.parabola.mkgmap.general.MapShape;

import org.junit.Test;
import static org.junit.Assert.*;

/**
 * Test polygon splitting
 * @author Ticker Berkin
 *
 */
public class ShapeSplitterTest {

@Test
public void test1_SimpleSplit() {
	// simple diamond shape
	int[][] os = { {1,1}, {5,3}, {7,7}, {3,5} };
	splitTester st = new splitTester(os);
	
	st.cutPosn(3, false);
	int[][] f1 = { {1,1}, {3,2}, {3,5} };
	st.addExpected(f1);
	int[][] f2 = { {3,2}, {5,3}, {7,7}, {3,5} };
	st.addExpected(f2);
	st.cutWithSplitShape();
	st.cutWithClipToBounds();
	st.cutWithJava2D();
	
	st.cutPosn(5, true);
	int[][] t1 = { {1,1}, {5,3}, {6,5}, {3,5} };
	st.addExpected(t1);
	int[][] t2 = { {6,5}, {7,7}, {3,5} };
	st.addExpected(t2);
	st.cutWithSplitShape();
	st.cutWithClipToBounds();
	st.cutWithJava2D();
}

@Test
public void test2_cutToHole() {
	// shape has hole with cut to get to it
	int[][] os = { {1,1}, {3,1}, {3,3}, {2,3}, {2,4}, {4,4}, {4,3}, {3,3}, {3,1}, {5,1}, {5,5}, {1,5} };
	splitTester st = new splitTester(os);

	// cut across existing cut
	st.cutPosn(2, true);
	int[][] t1 = { {1,1}, {3,1}, {3,2}, {1,2} };
	st.addExpected(t1);
	int[][] t2 = { {3,1}, {5,1}, {5,2}, {3,2} };
	st.addExpected(t2);
	int[][] t3 = { {1,2}, {3,2}, {3,3}, {2,3}, {2,4}, {4,4}, {4,3}, {3,3}, {3,2}, {5,2}, {5,5}, {1,5} };
	st.addExpected(t3);
	st.cutWithSplitShape();
	st.cutWithClipToBounds();
//!!!	st.cutWithJava2D();  !!! java2D can't handle this
	
	// cut along cut and through other side of hole
	st.cutPosn(3, false);
	int[][] f1 = { {1,1}, {3,1}, {3,3}, {2,3}, {2,4}, {3,4}, {3,5}, {1,5} };
	st.addExpected(f1);
	int[][] f2 = { {3,1}, {5,1}, {5,5}, {3,5}, {3,4},