date:20210607

Re: [mkgmap-dev] low-res-opt branch: error message from ShapeSplitter for self-intersecting multipolygon

2021-06-07 Thread Ticker Berkin


Hi Gerd

The shape is a figure-of-8 so shapesSplitter needs to give some error.

If this isn't an original OSM shape, it points to some problem with 
earlier processing, probably shape-merging. Although it might render 
(could be device dependent), further processing (eg overview merging) 
could come to grief.


Ticker

On 07/06/2021 10:24, Gerd Petermann wrote:

Hi Ticker,

okay, no problem, I'll work on the faster-mp branch in the mean time
Maybe I'll merge it first into the low-res-opt branch.

Gerd


Von: mkgmap-dev  im Auftrag von Ticker Berkin 

Gesendet: Montag, 7. Juni 2021 11:23
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] low-res-opt branch: error message from ShapeSplitter 
for self-intersecting multipolygon

Hi Gerd

The shape I'm getting in my build has a major problem with a twist
between the 2 parts. I'm having trouble reconciling it with the OSM
map. I've attached the original shape trace.

I agree that some of the messages do need tweaking, but, in this cases
there is a significant problem.

I'll consider the types of messages etc in the new version I'm working
on.

I'm away for a few days and won't be able to do much remotely.

Ticker

On Mon, 2021-06-07 at 07:22 +, Gerd Petermann wrote:

Hi Ticker,

please check https://files.mkgmap.org.uk/download/512/63240024.o5m
with (unpatched) r4756 and these options --generate
-sea=multipolygon,floodblocker --preserve-element-order --order-by
-decreasing-area
--allow-reverse-merge

Produces an error message
SCHWERWIEGEND (ShapeSplitter):
e:\osm_out_work\norway\20210511_095323\63240024.o5m: Vertical split
36691968 failed on shape at
http://www.openstreetmap.org/?mlat=65.979056&mlon=12.308790&zoom=17 P
ossibly a self-intersecting polygon
for this invalid multipolygon :
https://www.openstreetmap.org/relation/5294624

The result doesn't look wrong, so I think there should either be no
error message or we need code to remove those self-intersections or
ignore invalid MP like that?

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

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


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

Re: [mkgmap-dev] Proof of concept for better sea in overview map

2021-06-07 Thread Gerd Petermann

Hi Felix,

the map contained was without routing or index, so for a normal map the 
difference should be even smaller.
There is no need to change sea.zip. You just have to use --improve-overview for 
now.

Gerd

Von: mkgmap-dev  im Auftrag von Felix 
Hartmann 
Gesendet: Montag, 7. Juni 2021 21:02
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map

I guess that is a time for a full Norway map based on default style - so that 
is quite okay. Not a sea only Norway map... Well I hope that Thorsten Kukuk can 
adapt his sea files in the near future then...

On Mon, 7 Jun 2021 at 19:37, Gerd Petermann 
mailto:gpetermann_muenc...@hotmail.com>> wrote:
OK, I think found a good solution. Speed is quite OK, I see  9 min 48 secs for 
map of norway and instead of 8 min 44 secs with  r4756, and I consider Norway 
to be a worst case.

See https://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4761 for 
the details.

Gerd

Von: mkgmap-dev 
mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>>
 im Auftrag von Gerd Petermann 
mailto:gpetermann_muenc...@hotmail.com>>
Gesendet: Montag, 7. Juni 2021 12:11
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map

With the provided patch the speed is very poor for areas like Norway, probably 
twice the time.
It is much slower because it does the complex multipolygon cutting for each 
level in the overview map. Probably too slow for complex coastal areas.
This time will be the same for precomp-sea unless we can store sea polygons for 
each resolution.

Performance will be no problem if I find a way to use Douglas-Peucker or 
similar before cutting. That was my original idea but DP produces self 
intersecting polygons and the MultipolygonCutter cannot cope with that.

Gerd

Von: mkgmap-dev 
mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>>
 im Auftrag von Felix Hartmann 
mailto:extremecar...@gmail.com>>
Gesendet: Montag, 7. Juni 2021 11:55
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map

Is it only much slower because of not using precomp sea? Or will it be much 
slower in general? And what is much slower for say Europe continent map? If a 
modern 4core/8thread processor needs 30 minutes more I would prefer the old way 
knowing it is worse (if the time difference is negligible with precomp-sea then 
that would be great).

On Mon, 7 Jun 2021 at 12:26, Ticker Berkin 
mailto:rwb-mkg...@jagit.co.uk>>>
 wrote:
Hi Gerd

This is going to take some studying to work out the implications. Can't
do much for the next few days however, but will look carefully at the
end of the week.

Ticker

On Sun, 2021-06-06 at 14:02 +, Gerd Petermann wrote:
> Hi,
>
> the attached patch improves the overview map, but so far only when
> precomp-sea is NOT used.
> I tested it with --generate-sea=multipolygon,floodblocker  so that
> mkgmap really has a multipolygon with the natual=sea data.
>
> For each level in the overview map it uses the original multipolygon
> data to compute the rings which will might visible at the given
> resolution. This requires more time compared to the current code but
> the result is much better and some fine tuning is possible.
>
> To be able to use this also with --precomp-sea we need some changes
> in the code which generates sea.zip so that one multipolygon relation
> for each tile is stored.
>
> I've uploaded the results here:
> https://files.mkgmap.org.uk/download/511/compare.7z
> What do you think?
>
> Gerd
>
>
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk>
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk>
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

--
Felix Hartman - Openmtbmap.org & VeloMap.org

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

--
Felix Hartman - Openmtbmap.org & VeloMap.org

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

Re: [mkgmap-dev] Proof of concept for better sea in overview map

2021-06-07 Thread Felix Hartmann

I guess that is a time for a full Norway map based on default style - so
that is quite okay. Not a sea only Norway map... Well I hope that Thorsten
Kukuk can adapt his sea files in the near future then...

On Mon, 7 Jun 2021 at 19:37, Gerd Petermann 
wrote:

> OK, I think found a good solution. Speed is quite OK, I see  9 min 48 secs
> for map of norway and instead of 8 min 44 secs with  r4756, and I consider
> Norway to be a worst case.
>
> See https://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4761
> for the details.
>
> Gerd
>
>
> 
> Von: mkgmap-dev  im Auftrag von
> Gerd Petermann 
> Gesendet: Montag, 7. Juni 2021 12:11
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map
>
> With the provided patch the speed is very poor for areas like Norway,
> probably twice the time.
> It is much slower because it does the complex multipolygon cutting for
> each level in the overview map. Probably too slow for complex coastal areas.
> This time will be the same for precomp-sea unless we can store sea
> polygons for each resolution.
>
> Performance will be no problem if I find a way to use Douglas-Peucker or
> similar before cutting. That was my original idea but DP produces self
> intersecting polygons and the MultipolygonCutter cannot cope with that.
>
> Gerd
>
> 
> Von: mkgmap-dev  im Auftrag von
> Felix Hartmann 
> Gesendet: Montag, 7. Juni 2021 11:55
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map
>
> Is it only much slower because of not using precomp sea? Or will it be
> much slower in general? And what is much slower for say Europe continent
> map? If a modern 4core/8thread processor needs 30 minutes more I would
> prefer the old way knowing it is worse (if the time difference is
> negligible with precomp-sea then that would be great).
>
> On Mon, 7 Jun 2021 at 12:26, Ticker Berkin  rwb-mkg...@jagit.co.uk>> wrote:
> Hi Gerd
>
> This is going to take some studying to work out the implications. Can't
> do much for the next few days however, but will look carefully at the
> end of the week.
>
> Ticker
>
> On Sun, 2021-06-06 at 14:02 +, Gerd Petermann wrote:
> > Hi,
> >
> > the attached patch improves the overview map, but so far only when
> > precomp-sea is NOT used.
> > I tested it with --generate-sea=multipolygon,floodblocker  so that
> > mkgmap really has a multipolygon with the natual=sea data.
> >
> > For each level in the overview map it uses the original multipolygon
> > data to compute the rings which will might visible at the given
> > resolution. This requires more time compared to the current code but
> > the result is much better and some fine tuning is possible.
> >
> > To be able to use this also with --precomp-sea we need some changes
> > in the code which generates sea.zip so that one multipolygon relation
> > for each tile is stored.
> >
> > I've uploaded the results here:
> > https://files.mkgmap.org.uk/download/511/compare.7z
> > What do you think?
> >
> > Gerd
> >
> >
> > ___
> > mkgmap-dev mailing list
> > mkgmap-dev@lists.mkgmap.org.uk
> > https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
>
> --
> Felix Hartman - Openmtbmap.org & VeloMap.org
>
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>


-- 
Felix Hartman - Openmtbmap.org & VeloMap.org
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Proof of concept for better sea in overview map

2021-06-07 Thread Gerd Petermann

OK, I think found a good solution. Speed is quite OK, I see  9 min 48 secs for 
map of norway and instead of 8 min 44 secs with  r4756, and I consider Norway 
to be a worst case.

See https://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4761 for 
the details.

Gerd

Von: mkgmap-dev  im Auftrag von Gerd 
Petermann 
Gesendet: Montag, 7. Juni 2021 12:11
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map

With the provided patch the speed is very poor for areas like Norway, probably 
twice the time.
It is much slower because it does the complex multipolygon cutting for each 
level in the overview map. Probably too slow for complex coastal areas.
This time will be the same for precomp-sea unless we can store sea polygons for 
each resolution.

Performance will be no problem if I find a way to use Douglas-Peucker or 
similar before cutting. That was my original idea but DP produces self 
intersecting polygons and the MultipolygonCutter cannot cope with that.

Gerd

Von: mkgmap-dev  im Auftrag von Felix 
Hartmann 
Gesendet: Montag, 7. Juni 2021 11:55
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map

Is it only much slower because of not using precomp sea? Or will it be much 
slower in general? And what is much slower for say Europe continent map? If a 
modern 4core/8thread processor needs 30 minutes more I would prefer the old way 
knowing it is worse (if the time difference is negligible with precomp-sea then 
that would be great).

On Mon, 7 Jun 2021 at 12:26, Ticker Berkin 
mailto:rwb-mkg...@jagit.co.uk>> wrote:
Hi Gerd

This is going to take some studying to work out the implications. Can't
do much for the next few days however, but will look carefully at the
end of the week.

Ticker

On Sun, 2021-06-06 at 14:02 +, Gerd Petermann wrote:
> Hi,
>
> the attached patch improves the overview map, but so far only when
> precomp-sea is NOT used.
> I tested it with --generate-sea=multipolygon,floodblocker  so that
> mkgmap really has a multipolygon with the natual=sea data.
>
> For each level in the overview map it uses the original multipolygon
> data to compute the rings which will might visible at the given
> resolution. This requires more time compared to the current code but
> the result is much better and some fine tuning is possible.
>
> To be able to use this also with --precomp-sea we need some changes
> in the code which generates sea.zip so that one multipolygon relation
> for each tile is stored.
>
> I've uploaded the results here:
> https://files.mkgmap.org.uk/download/511/compare.7z
> What do you think?
>
> Gerd
>
>
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

--
Felix Hartman - Openmtbmap.org & VeloMap.org

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

Re: [mkgmap-dev] Proof of concept for better sea in overview map

2021-06-07 Thread Gerd Petermann

With the provided patch the speed is very poor for areas like Norway, probably 
twice the time.
It is much slower because it does the complex multipolygon cutting for each 
level in the overview map. Probably too slow for complex coastal areas.
This time will be the same for precomp-sea unless we can store sea polygons for 
each resolution.

Performance will be no problem if I find a way to use Douglas-Peucker or 
similar before cutting. That was my original idea but DP produces self 
intersecting polygons and the MultipolygonCutter cannot cope with that.

Gerd

Von: mkgmap-dev  im Auftrag von Felix 
Hartmann 
Gesendet: Montag, 7. Juni 2021 11:55
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map

Is it only much slower because of not using precomp sea? Or will it be much 
slower in general? And what is much slower for say Europe continent map? If a 
modern 4core/8thread processor needs 30 minutes more I would prefer the old way 
knowing it is worse (if the time difference is negligible with precomp-sea then 
that would be great).

On Mon, 7 Jun 2021 at 12:26, Ticker Berkin 
mailto:rwb-mkg...@jagit.co.uk>> wrote:
Hi Gerd

This is going to take some studying to work out the implications. Can't
do much for the next few days however, but will look carefully at the
end of the week.

Ticker

On Sun, 2021-06-06 at 14:02 +, Gerd Petermann wrote:
> Hi,
>
> the attached patch improves the overview map, but so far only when
> precomp-sea is NOT used.
> I tested it with --generate-sea=multipolygon,floodblocker  so that
> mkgmap really has a multipolygon with the natual=sea data.
>
> For each level in the overview map it uses the original multipolygon
> data to compute the rings which will might visible at the given
> resolution. This requires more time compared to the current code but
> the result is much better and some fine tuning is possible.
>
> To be able to use this also with --precomp-sea we need some changes
> in the code which generates sea.zip so that one multipolygon relation
> for each tile is stored.
>
> I've uploaded the results here:
> https://files.mkgmap.org.uk/download/511/compare.7z
> What do you think?
>
> Gerd
>
>
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

--
Felix Hartman - Openmtbmap.org & VeloMap.org

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

Re: [mkgmap-dev] Proof of concept for better sea in overview map

2021-06-07 Thread Felix Hartmann

Is it only much slower because of not using precomp sea? Or will it be much
slower in general? And what is much slower for say Europe continent map? If
a modern 4core/8thread processor needs 30 minutes more I would prefer the
old way knowing it is worse (if the time difference is negligible with
precomp-sea then that would be great).

On Mon, 7 Jun 2021 at 12:26, Ticker Berkin  wrote:

> Hi Gerd
>
> This is going to take some studying to work out the implications. Can't
> do much for the next few days however, but will look carefully at the
> end of the week.
>
> Ticker
>
> On Sun, 2021-06-06 at 14:02 +, Gerd Petermann wrote:
> > Hi,
> >
> > the attached patch improves the overview map, but so far only when
> > precomp-sea is NOT used.
> > I tested it with --generate-sea=multipolygon,floodblocker  so that
> > mkgmap really has a multipolygon with the natual=sea data.
> >
> > For each level in the overview map it uses the original multipolygon
> > data to compute the rings which will might visible at the given
> > resolution. This requires more time compared to the current code but
> > the result is much better and some fine tuning is possible.
> >
> > To be able to use this also with --precomp-sea we need some changes
> > in the code which generates sea.zip so that one multipolygon relation
> > for each tile is stored.
> >
> > I've uploaded the results here:
> > https://files.mkgmap.org.uk/download/511/compare.7z
> > What do you think?
> >
> > Gerd
> >
> >
> > ___
> > mkgmap-dev mailing list
> > mkgmap-dev@lists.mkgmap.org.uk
> > https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>


-- 
Felix Hartman - Openmtbmap.org & VeloMap.org
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Proof of concept for better sea in overview map

2021-06-07 Thread Ticker Berkin

Hi Gerd

This is going to take some studying to work out the implications. Can't
do much for the next few days however, but will look carefully at the
end of the week.

Ticker

On Sun, 2021-06-06 at 14:02 +, Gerd Petermann wrote:
> Hi,
> 
> the attached patch improves the overview map, but so far only when
> precomp-sea is NOT used. 
> I tested it with --generate-sea=multipolygon,floodblocker  so that
> mkgmap really has a multipolygon with the natual=sea data.
> 
> For each level in the overview map it uses the original multipolygon
> data to compute the rings which will might visible at the given
> resolution. This requires more time compared to the current code but
> the result is much better and some fine tuning is possible.
> 
> To be able to use this also with --precomp-sea we need some changes
> in the code which generates sea.zip so that one multipolygon relation
> for each tile is stored. 
> 
> I've uploaded the results here: 
> https://files.mkgmap.org.uk/download/511/compare.7z
> What do you think?
> 
> Gerd
> 
> 
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] low-res-opt branch: error message from ShapeSplitter for self-intersecting multipolygon

2021-06-07 Thread Gerd Petermann

Hi Ticker,

okay, no problem, I'll work on the faster-mp branch in the mean time
Maybe I'll merge it first into the low-res-opt branch.

Gerd

Von: mkgmap-dev  im Auftrag von Ticker 
Berkin 
Gesendet: Montag, 7. Juni 2021 11:23
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] low-res-opt branch: error message from ShapeSplitter 
for self-intersecting multipolygon

Hi Gerd

The shape I'm getting in my build has a major problem with a twist
between the 2 parts. I'm having trouble reconciling it with the OSM
map. I've attached the original shape trace.

I agree that some of the messages do need tweaking, but, in this cases
there is a significant problem.

I'll consider the types of messages etc in the new version I'm working
on.

I'm away for a few days and won't be able to do much remotely.

Ticker

On Mon, 2021-06-07 at 07:22 +, Gerd Petermann wrote:
> Hi Ticker,
>
> please check https://files.mkgmap.org.uk/download/512/63240024.o5m
> with (unpatched) r4756 and these options --generate
> -sea=multipolygon,floodblocker --preserve-element-order --order-by
> -decreasing-area
> --allow-reverse-merge
>
> Produces an error message
> SCHWERWIEGEND (ShapeSplitter):
> e:\osm_out_work\norway\20210511_095323\63240024.o5m: Vertical split
> 36691968 failed on shape at
> http://www.openstreetmap.org/?mlat=65.979056&mlon=12.308790&zoom=17 P
> ossibly a self-intersecting polygon
> for this invalid multipolygon :
> https://www.openstreetmap.org/relation/5294624
>
> The result doesn't look wrong, so I think there should either be no
> error message or we need code to remove those self-intersections or
> ignore invalid MP like that?
>
> Gerd
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] low-res-opt branch: error message from ShapeSplitter for self-intersecting multipolygon

2021-06-07 Thread Ticker Berkin

Hi Gerd

The shape I'm getting in my build has a major problem with a twist
between the 2 parts. I'm having trouble reconciling it with the OSM
map. I've attached the original shape trace.

I agree that some of the messages do need tweaking, but, in this cases
there is a significant problem.

I'll consider the types of messages etc in the new version I'm working
on.

I'm away for a few days and won't be able to do much remotely.

Ticker

On Mon, 2021-06-07 at 07:22 +, Gerd Petermann wrote:
> Hi Ticker,
> 
> please check https://files.mkgmap.org.uk/download/512/63240024.o5m
> with (unpatched) r4756 and these options --generate
> -sea=multipolygon,floodblocker --preserve-element-order --order-by
> -decreasing-area
> --allow-reverse-merge  
> 
> Produces an error message
> SCHWERWIEGEND (ShapeSplitter):
> e:\osm_out_work\norway\20210511_095323\63240024.o5m: Vertical split
> 36691968 failed on shape at 
> http://www.openstreetmap.org/?mlat=65.979056&mlon=12.308790&zoom=17 P
> ossibly a self-intersecting polygon
> for this invalid multipolygon : 
> https://www.openstreetmap.org/relation/5294624
> 
> The result doesn't look wrong, so I think there should either be no
> error message or we need code to remove those self-intersections or
> ignore invalid MP like that?
> 
> Gerd
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-devhttp://www.topografix.com/GPX/1/1"; creator="mkgmap" version="1.1" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; 
xsi:schemaLocation="http://www.topografix.com/GPX/1/1 
http://www.topografix.com/GPX/1/1/gpx.xsd";> 
V36691968_3074847/S_hp___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] low-res-opt branch: error message from ShapeSplitter for self-intersecting multipolygon

2021-06-07 Thread Gerd Petermann

Hi Ticker,

please check https://files.mkgmap.org.uk/download/512/63240024.o5m
with (unpatched) r4756 and these options 
--generate-sea=multipolygon,floodblocker --preserve-element-order 
--order-by-decreasing-area
--allow-reverse-merge  

Produces an error message
SCHWERWIEGEND (ShapeSplitter): 
e:\osm_out_work\norway\20210511_095323\63240024.o5m: Vertical split 36691968 
failed on shape at 
http://www.openstreetmap.org/?mlat=65.979056&mlon=12.308790&zoom=17 Possibly a 
self-intersecting polygon
for this invalid multipolygon : https://www.openstreetmap.org/relation/5294624

The result doesn't look wrong, so I think there should either be no error 
message or we need code to remove those self-intersections or ignore invalid MP 
like that?

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

Re: [mkgmap-dev] low-res-opt branch: error message from ShapeSplitter for self-intersecting multipolygon

Re: [mkgmap-dev] Proof of concept for better sea in overview map

Re: [mkgmap-dev] Proof of concept for better sea in overview map

Re: [mkgmap-dev] Proof of concept for better sea in overview map

Re: [mkgmap-dev] Proof of concept for better sea in overview map

Re: [mkgmap-dev] Proof of concept for better sea in overview map

Re: [mkgmap-dev] Proof of concept for better sea in overview map

Re: [mkgmap-dev] low-res-opt branch: error message from ShapeSplitter for self-intersecting multipolygon

Re: [mkgmap-dev] low-res-opt branch: error message from ShapeSplitter for self-intersecting multipolygon

[mkgmap-dev] low-res-opt branch: error message from ShapeSplitter for self-intersecting multipolygon

10 matches

Site Navigation

Mail list logo

Footer information