Re: [mkgmap-dev] style file reader patch

[Mike Baggaley]

Bizarre, I have just reinstated the original code for handling UTF-8 and it
is no longer crashing. Can't think of anything I've changed in the
environment, other than the points file now contains a lot more statements
in it. I'll leave the original code in place and see if the crash recurs and
if so try to find out what exactly is happening.

Regards,
Mike

-Original Message-
From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com] 
Sent: 19 January 2017 12:25
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] style file reader patch

Hi Mike,

I am also using Windows.

Gerd


Von: mkgmap-dev  im Auftrag von Mike
Baggaley 
Gesendet: Donnerstag, 19. Januar 2017 13:20:16
An: 'Development list for mkgmap'
Betreff: Re: [mkgmap-dev] style file reader patch

Hi Gerd, This may be a platform specific problem. I am running on Windows.
Notepad and Visual Studio say my file is UTF-8 encoded, but it fails to load
with the accented character in it. It does load with the patch. Is there
anyone else using Windows who can try the line?

Regards,
Mike

-Original Message-
From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com]
Sent: 18 January 2017 13:52
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] style file reader patch

Hi Mike,

I am not able to reproduce the problem. I've added the line to the default
style points file
and mkgmap doesn't complain about it.
My editor (PSPad) "says" that the points file is a utf-8 encoded unix  file,
a hex editor shows no BOM.

Gerd


Von: mkgmap-dev  im Auftrag von Mike
Baggaley 
Gesendet: Samstag, 14. Januar 2017 23:21:22
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: [mkgmap-dev] style file reader patch

Hi Gerd, I have found that the style file reader does handle non ASCII
characters properly. With the following line in my points file:

amenity=cafe & name~'[Cc]af[eé]' {echotags 'Description as name'; delete
name}

I get an error:

Error in style : error : (points:142): Bad character in input, file probably
not in utf-8

This happens whether or not I save the points file as UTF-8.

The attached patch fixes the problem.

Can you please try it and commit if it is OK (you may want to change the
RuntimeException)?

Thanks,
Mike



___
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] Multipolygon-Relation checks in mkgmap

[Gerd Petermann]

Hi Ticker,

okay, I'll have a look at the branch. The problem  in 
http://www.openstreetmap.org/relation/2199651
is solved with r3773, but your case looks different.

Gerd


Von: mkgmap-dev  im Auftrag von Ticker 
Berkin 
Gesendet: Mittwoch, 25. Januar 2017 15:56:06
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] Multipolygon-Relation checks in mkgmap

Hi Gerd

Using your split of germany, 63240135.osm.pbf gives me the problem
after I converted PolygonSplitterBase and AreaClipper to the new algo

It is the outer way of relation/27312 at 48.94071,13.70245
At highest resolution, openStreetMap shows no intersection, but when I
dump the highRes points after the split complains and plot them it
shows an overlap.

Ticker

On Wed, 2017-01-25 at 14:29 +, Gerd Petermann wrote:
> Hi Ticker,
>
> do you have an example for such a problem case?
>
> Gerd
>
> 
> Von: mkgmap-dev  im Auftrag
> von Ticker Berkin 
> Gesendet: Mittwoch, 25. Januar 2017 13:25:34
> An: mkgmap-dev@lists.mkgmap.org.uk
> Betreff: Re: [mkgmap-dev] Multipolygon-Relation checks in mkgmap
>
> Hi Gerd
>
> Yes - please
>
> I started looking at MultiPolygonRelation yesterday with a view of
> trying to convert it to use the new ShapeSplitter algorithm.
>
> I think that the way a self-intersecting polygon is rewritten after a
> split using the Java2D library causes problems for the new algorithm
> when it makes a later cut for points limits or subdivisions, even
> when
> the next cut isn't in the overlapped area.
>
> All I've done so far is convert a few more places to use highPrec
> logic
> and then slightly disparaging at the complexity of the whole thing.
>
> Ticker
>
> On Wed, 2017-01-25 at 09:05 +, Gerd Petermann wrote:
> > Hi all,
> >
> > I'd like to rewrite the code in MultiPolygonRelation so that it
> > tolerates more mp-rels.
> > For example, the relation
> > http://www.openstreetmap.org/relation/2199651
> > produces these warnings:
> > WARN: uk.me.parabola.mkgmap.reader.osm.MultiPolygonRelation
> >  f:\osm\rel2199651.osm: Some polygons are intersecting. This is not
> > allowed in multipolygons.
> > WARN: uk.me.parabola.mkgmap.reader.osm.MultiPolygonRelation
> >  f:\osm\rel2199651.osm: -
> > http://www.openstreetmap.org/way/165084794
> > WARN: uk.me.parabola.mkgmap.reader.osm.MultiPolygonRelation
> >  f:\osm\rel2199651.osm: -
> > http://www.openstreetmap.org/way/165084810
> > WARN: uk.me.parabola.mkgmap.reader.osm.MultiPolygonRelation
> >  f:\osm\rel2199651.osm: Polygon
> > 4611686018427387906(8P)(165084810[8P]) carries role inner but is
> > not
> > inside any other polygon. Potentially it does not belong to this
> > multipolygon.
> > The inner way touches the outer way in one point. My understanding
> > is
> > that this is correct, mkgmap should not complain about it.
> >
> >  OK?
> > 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
> ___
> 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] Commit r3773: let linesCutEachOther() return false if the two line segments meat at an end point

[svn commit]

Version mkgmap-r3773 was committed by gerd on Wed, 25 Jan 2017

let linesCutEachOther() return false if the two line segments meat at an end 
point

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

Re: [mkgmap-dev] new branch split-shape

[Ticker Berkin]

Hi Gerd

OK.

Re. sea polygons: These shouldn't go into their own subDivision because
it will stop mkgmap:drawLevel from working correctly.

Ticker

PS I've committed more changes to branches/split-shape, including my
initial changes to MultiPolygonRelation - Take this if you want, so far
it doesn't have any dependencies on the new algo

Ticker

On Wed, 2017-01-25 at 09:07 +, Gerd Petermann wrote:
> Hi Ticker,
> 
> merging earlier seems to require quite heavy changes, so I gave up.
> 
> Gerd
> 
> 
> Von: mkgmap-dev  im Auftrag
> von Gerd Petermann 
> Gesendet: Montag, 23. Januar 2017 11:01:11
> An: mkgmap-dev@lists.mkgmap.org.uk
> Betreff: Re: [mkgmap-dev] new branch split-shape
> 
> Hi Ticker,
> 
> Ticker Berkin wrote
> > What aspect of sea polygons is getting worse?
> 
> GPSMapEdit reports that the shapes require more memory, I think that
> means
> that --order-by-decreasing-area
> option still creates more shapes. Same problem with background shapes
> (0x4B).
> A quick work around might be to place those large polygons into their
> own
> sub divs.
> I am experimenting with this idea and with an earlier shape merge.
> 
> 
> Ticker Berkin wrote
> > Once the new algo is shown not to cause problems: for quick/simple
> > wins, I'd like to convert PolygonSplitter*, AreaClipper and
> > MultiPolygonRelation to use the new code.
> 
> OK, go ahead.
> 
> Gerd
> 
> 
> 
> 
> 
> --
> View this message in context: http://gis.19327.n8.nabble.com/new-bran
> ch-split-shape-tp5889303p5889811.html
> Sent from the Mkgmap Development mailing list archive at Nabble.com.
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] Commit r3772: clean up MultiPolygonRelation, no functional change

[svn commit]

Version mkgmap-r3772 was committed by gerd on Wed, 25 Jan 2017

clean up MultiPolygonRelation, no functional change

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

Re: [mkgmap-dev] Multipolygon-Relation checks in mkgmap

[Ticker Berkin]

Hi Gerd

Using your split of germany, 63240135.osm.pbf gives me the problem
after I converted PolygonSplitterBase and AreaClipper to the new algo

It is the outer way of relation/27312 at 48.94071,13.70245
At highest resolution, openStreetMap shows no intersection, but when I
dump the highRes points after the split complains and plot them it
shows an overlap.

Ticker

On Wed, 2017-01-25 at 14:29 +, Gerd Petermann wrote:
> Hi Ticker,
> 
> do you have an example for such a problem case?
> 
> Gerd
> 
> 
> Von: mkgmap-dev  im Auftrag
> von Ticker Berkin 
> Gesendet: Mittwoch, 25. Januar 2017 13:25:34
> An: mkgmap-dev@lists.mkgmap.org.uk
> Betreff: Re: [mkgmap-dev] Multipolygon-Relation checks in mkgmap
> 
> Hi Gerd
> 
> Yes - please
> 
> I started looking at MultiPolygonRelation yesterday with a view of
> trying to convert it to use the new ShapeSplitter algorithm.
> 
> I think that the way a self-intersecting polygon is rewritten after a
> split using the Java2D library causes problems for the new algorithm
> when it makes a later cut for points limits or subdivisions, even
> when
> the next cut isn't in the overlapped area.
> 
> All I've done so far is convert a few more places to use highPrec
> logic
> and then slightly disparaging at the complexity of the whole thing.
> 
> Ticker
> 
> On Wed, 2017-01-25 at 09:05 +, Gerd Petermann wrote:
> > Hi all,
> > 
> > I'd like to rewrite the code in MultiPolygonRelation so that it
> > tolerates more mp-rels.
> > For example, the relation
> > http://www.openstreetmap.org/relation/2199651
> > produces these warnings:
> > WARN: uk.me.parabola.mkgmap.reader.osm.MultiPolygonRelation
> >  f:\osm\rel2199651.osm: Some polygons are intersecting. This is not
> > allowed in multipolygons.
> > WARN: uk.me.parabola.mkgmap.reader.osm.MultiPolygonRelation
> >  f:\osm\rel2199651.osm: - 
> > http://www.openstreetmap.org/way/165084794
> > WARN: uk.me.parabola.mkgmap.reader.osm.MultiPolygonRelation
> >  f:\osm\rel2199651.osm: - 
> > http://www.openstreetmap.org/way/165084810
> > WARN: uk.me.parabola.mkgmap.reader.osm.MultiPolygonRelation
> >  f:\osm\rel2199651.osm: Polygon
> > 4611686018427387906(8P)(165084810[8P]) carries role inner but is
> > not
> > inside any other polygon. Potentially it does not belong to this
> > multipolygon.
> > The inner way touches the outer way in one point. My understanding
> > is
> > that this is correct, mkgmap should not complain about it.
> > 
> >  OK?
> > 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
> ___
> 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] Multipolygon-Relation checks in mkgmap

[Gerd Petermann]

Hi Ticker,

do you have an example for such a problem case?

Gerd


Von: mkgmap-dev  im Auftrag von Ticker 
Berkin 
Gesendet: Mittwoch, 25. Januar 2017 13:25:34
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] Multipolygon-Relation checks in mkgmap

Hi Gerd

Yes - please

I started looking at MultiPolygonRelation yesterday with a view of
trying to convert it to use the new ShapeSplitter algorithm.

I think that the way a self-intersecting polygon is rewritten after a
split using the Java2D library causes problems for the new algorithm
when it makes a later cut for points limits or subdivisions, even when
the next cut isn't in the overlapped area.

All I've done so far is convert a few more places to use highPrec logic
and then slightly disparaging at the complexity of the whole thing.

Ticker

On Wed, 2017-01-25 at 09:05 +, Gerd Petermann wrote:
> Hi all,
>
> I'd like to rewrite the code in MultiPolygonRelation so that it
> tolerates more mp-rels.
> For example, the relation
> http://www.openstreetmap.org/relation/2199651
> produces these warnings:
> WARN: uk.me.parabola.mkgmap.reader.osm.MultiPolygonRelation
>  f:\osm\rel2199651.osm: Some polygons are intersecting. This is not
> allowed in multipolygons.
> WARN: uk.me.parabola.mkgmap.reader.osm.MultiPolygonRelation
>  f:\osm\rel2199651.osm: - http://www.openstreetmap.org/way/165084794
> WARN: uk.me.parabola.mkgmap.reader.osm.MultiPolygonRelation
>  f:\osm\rel2199651.osm: - http://www.openstreetmap.org/way/165084810
> WARN: uk.me.parabola.mkgmap.reader.osm.MultiPolygonRelation
>  f:\osm\rel2199651.osm: Polygon
> 4611686018427387906(8P)(165084810[8P]) carries role inner but is not
> inside any other polygon. Potentially it does not belong to this
> multipolygon.
> The inner way touches the outer way in one point. My understanding is
> that this is correct, mkgmap should not complain about it.
>
>  OK?
> 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
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Multipolygon-Relation checks in mkgmap

[Ticker Berkin]

Hi Gerd

Yes - please

I started looking at MultiPolygonRelation yesterday with a view of
trying to convert it to use the new ShapeSplitter algorithm.

I think that the way a self-intersecting polygon is rewritten after a
split using the Java2D library causes problems for the new algorithm
when it makes a later cut for points limits or subdivisions, even when
the next cut isn't in the overlapped area. 

All I've done so far is convert a few more places to use highPrec logic
and then slightly disparaging at the complexity of the whole thing.

Ticker

On Wed, 2017-01-25 at 09:05 +, Gerd Petermann wrote:
> Hi all,
> 
> I'd like to rewrite the code in MultiPolygonRelation so that it
> tolerates more mp-rels.
> For example, the relation  
> http://www.openstreetmap.org/relation/2199651
> produces these warnings:
> WARN: uk.me.parabola.mkgmap.reader.osm.MultiPolygonRelation 
>  f:\osm\rel2199651.osm: Some polygons are intersecting. This is not
> allowed in multipolygons.
> WARN: uk.me.parabola.mkgmap.reader.osm.MultiPolygonRelation 
>  f:\osm\rel2199651.osm: - http://www.openstreetmap.org/way/165084794
> WARN: uk.me.parabola.mkgmap.reader.osm.MultiPolygonRelation 
>  f:\osm\rel2199651.osm: - http://www.openstreetmap.org/way/165084810
> WARN: uk.me.parabola.mkgmap.reader.osm.MultiPolygonRelation 
>  f:\osm\rel2199651.osm: Polygon
> 4611686018427387906(8P)(165084810[8P]) carries role inner but is not
> inside any other polygon. Potentially it does not belong to this
> multipolygon.
> The inner way touches the outer way in one point. My understanding is
> that this is correct, mkgmap should not complain about it.
> 
>  OK?
> 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

[mkgmap-dev] Multipolygon-Relation checks in mkgmap

[Gerd Petermann]

Hi all,

I'd like to rewrite the code in MultiPolygonRelation so that it tolerates more 
mp-rels.
For example, the relation  http://www.openstreetmap.org/relation/2199651
produces these warnings:
WARN: uk.me.parabola.mkgmap.reader.osm.MultiPolygonRelation  
f:\osm\rel2199651.osm: Some polygons are intersecting. This is not allowed in 
multipolygons.
WARN: uk.me.parabola.mkgmap.reader.osm.MultiPolygonRelation  
f:\osm\rel2199651.osm: - http://www.openstreetmap.org/way/165084794
WARN: uk.me.parabola.mkgmap.reader.osm.MultiPolygonRelation  
f:\osm\rel2199651.osm: - http://www.openstreetmap.org/way/165084810
WARN: uk.me.parabola.mkgmap.reader.osm.MultiPolygonRelation  
f:\osm\rel2199651.osm: Polygon 4611686018427387906(8P)(165084810[8P]) carries 
role inner but is not inside any other polygon. Potentially it does not belong 
to this multipolygon.
The inner way touches the outer way in one point. My understanding is that this 
is correct, mkgmap should not complain about it.

 OK?
Gerd

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

Re: [mkgmap-dev] echo & echotags patch

[Gerd Petermann]

Thanks Mike,

committed with r3770.

Gerd


Von: mkgmap-dev  im Auftrag von Mike 
Baggaley 
Gesendet: Dienstag, 24. Januar 2017 15:52:23
An: 'Development list for mkgmap'
Betreff: [mkgmap-dev] echo & echotags patch

Hi Gerd, please find attached a small patch to echo and echotags. This
change improves the format of the messages such that the type of element is
included and the fake Id is replaced with a fragment saying the element has
been generated. The latter allows the output of different runs of mkgmap to
be compared without randomly generated Ids causing differences. I can't see
any need to know the actual fake Ids, just the fact that the element has
been generated should be sufficient. I have also removed "- " from echotags
and ":" from echo as unnecessary and inconsistent.

Existing message:
4611686018654788095 (1326812) -
[amenity=school,mkgmap:area2poi=true,name=School] Description as name

New message:
MultiPolygonPOINode generated from 1326812
[amenity=school,mkgmap:area2poi=true,name=School] Description as name

Can you please take a look and commit if happy?

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

[mkgmap-dev] Commit r3770: echo.patch by Mike Baggaley

[svn commit]

Version mkgmap-r3770 was committed by gerd on Wed, 25 Jan 2017

echo.patch by Mike Baggaley

This change improves the format of the messages such that the type of element is
included and the fake Id is replaced with a fragment saying the element has
been generated. The latter allows the output of different runs of mkgmap to
be compared without randomly generated Ids causing differences. I can't see
any need to know the actual fake Ids, just the fact that the element has
been generated should be sufficient. I have also removed "- " from echotags
and ":" from echo as unnecessary and inconsistent.

Existing message:
4611686018654788095 (1326812) -
[amenity=school,mkgmap:area2poi=true,name=School] Description as name

New message:
MultiPolygonPOINode generated from 1326812
[amenity=school,mkgmap:area2poi=true,name=School] Description as name


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