Distorted lines

classic Classic list List threaded Threaded
41 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Distorted lines

popej
Hi,

I observe badly looking lines. I have attached some pictures and xml
objects that doesn't look good on Garmin map.

My guess is that there is no proper simplifications for resolution
24bit. Points too dense are removed in a non optimal way which can lead
to jagged curves. This could be the reason for bad looking tram railways
(file tram1.osm in test.zip).

Other reason could be removing of short lines. I think in this case some
nodes are moved. It looks like instead of creating a new node in a
middle of removed line, first point is used. This can lead to bigger
distortion. This is probably the case of road example (file road1.osm).

--
Best regards,
Andrzej

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

road.png (13K) Download Attachment
road-osm.png (3K) Download Attachment
test.zip (2K) Download Attachment
tram.png (24K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Distorted lines

Gerd Petermann
Hi Andrzej,

I think there is no way to avoid the rounding errors caused by the 24b bit limit, but
some problems are definetely caused by the short-arc-removal routine which
merges nodes which are too close.
The weakness of the algo is that it doesn't care about the "importance" of a road
nor about the effect on straight lines.
I will need a few days to dig into this again.

Gerd


Date: Sun, 1 Sep 2013 03:48:17 +0200
From: [hidden email]
To: [hidden email]
Subject: [mkgmap-dev] Distorted lines

Hi,

I observe badly looking lines. I have attached some pictures and xml
objects that doesn't look good on Garmin map.

My guess is that there is no proper simplifications for resolution
24bit. Points too dense are removed in a non optimal way which can lead
to jagged curves. This could be the reason for bad looking tram railways
(file tram1.osm in test.zip).

Other reason could be removing of short lines. I think in this case some
nodes are moved. It looks like instead of creating a new node in a
middle of removed line, first point is used. This can lead to bigger
distortion. This is probably the case of road example (file road1.osm).

--
Best regards,
Andrzej

_______________________________________________ mkgmap-dev mailing list [hidden email] http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Distorted lines

Felix Hartmann-2
I noticed that remove-short-arcs=5.4 can in some cases even break routing, remove-short-arcs on default (I think 2.8) is fine though. I could well believe there are some fundamental flaws in it, especially in combinaton with reduce-point-density (--reduce-point-density=3.4 --reduce-point-density-polygon=6).

Maybe remove-short-arcs may not be bigger than the reduce-point-density values?
On 20.09.2013 09:47, Gerd Petermann wrote:
Hi Andrzej,

I think there is no way to avoid the rounding errors caused by the 24b bit limit, but
some problems are definetely caused by the short-arc-removal routine which
merges nodes which are too close.
The weakness of the algo is that it doesn't care about the "importance" of a road
nor about the effect on straight lines.
I will need a few days to dig into this again.

Gerd


Date: Sun, 1 Sep 2013 03:48:17 +0200
From: [hidden email]
To: [hidden email]
Subject: [mkgmap-dev] Distorted lines

Hi,
 
I observe badly looking lines. I have attached some pictures and xml 
objects that doesn't look good on Garmin map.
 
My guess is that there is no proper simplifications for resolution 
24bit. Points too dense are removed in a non optimal way which can lead 
to jagged curves. This could be the reason for bad looking tram railways 
(file tram1.osm in test.zip).
 
Other reason could be removing of short lines. I think in this case some 
nodes are moved. It looks like instead of creating a new node in a 
middle of removed line, first point is used. This can lead to bigger 
distortion. This is probably the case of road example (file road1.osm).
 
-- 
Best regards,
Andrzej

_______________________________________________ mkgmap-dev mailing list [hidden email] http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Distorted lines

Gerd Petermann
Hi Felix,
Felix Hartmann-2 wrote
I noticed that remove-short-arcs=5.4 can in some cases even break
routing, remove-short-arcs on default (I think 2.8) is fine though. I
could well believe there are some fundamental flaws in it, especially in
combinaton with reduce-point-density (--reduce-point-density=3.4
--reduce-point-density-polygon=6).

Maybe remove-short-arcs may not be bigger than the reduce-point-density
values?
I don't think so. Up to now the reduce-* values are only used for the simplifications that
are used for resoultions < 24,
while the remove-short-arcs value is used with the 24 bit value.

Gerd
Reply | Threaded
Open this post in threaded view
|

Re: Distorted lines

popej
Hi,

GerdP wrote:
 > Up to now the reduce-* values are only used for the
 > simplifications that are used for resoultions < 24

That is the first problem I have described. In my opinion,
simplification should be performed on original floating point data too.
This would preserve shape of the curve and eliminate small jaggies after
rounding to integer.

Second problem with deleted short lines is difficult to avoid but maybe
could be optimized for better visual result. Position of the point that
is replacing removed line could vary depending on topology of other
lines. Or sometimes instead of removing line, it could be extended a bit
with less impact on other lines.

--
Best regards,
Andrzej

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Distorted lines

Gerd Petermann
Hi Andrzej,

>
> Second problem with deleted short lines is difficult to avoid but maybe
> could be optimized for better visual result. Position of the point that
> is replacing removed line could vary depending on topology of other
> lines. Or sometimes instead of removing line, it could be extended a bit
> with less impact on other lines.

yes, that is what I am trying to implement.
There is a third option:
Sometimes mkgmap creates short arcs by changing the meaning of
points, eg. with the --link-pois-to-ways option. Some weeks ago I've
posted a patch regarding this, but I got no feedback. Did you try it?
See also
http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2013q2/018344.html

Gerd


_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Distorted lines

popej
Hi Gerd,

Gerd wrote:
 > Sometimes mkgmap creates short arcs by changing the meaning of
 > points, eg. with the --link-pois-to-ways option. Some weeks ago I've
 > posted a patch regarding this, but I got no feedback.

I didn't know about this patch. Now I have tried it but I can't see any
changes at places that I have provided in my first post. Maybe your
patch deals with other case.

--
Best
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Distorted lines

Gerd Petermann
Hi Andrzej ,

possible. I tried to describe the patch here:
http://gis.19327.n5.nabble.com/mergeroads-branch-tp5776711p5778385.html

I am working on a new patch for the short-arc-removal-algo.
In some cases, the algo can select which one of the two nodes
that build the short arc is to be merged.
I try to implement rules for these cases, e.g.
prefer to move the endpoint of a road rather than a point
in the middle (easy to implement).  If the roads have different road class,
prefer to move the smaller class (less easy)

Gerd

> Date: Sat, 21 Sep 2013 16:17:04 +0200

> From: [hidden email]
> To: [hidden email]
> Subject: Re: [mkgmap-dev] Distorted lines
>
> Hi Gerd,
>
> Gerd wrote:
> > Sometimes mkgmap creates short arcs by changing the meaning of
> > points, eg. with the --link-pois-to-ways option. Some weeks ago I've
> > posted a patch regarding this, but I got no feedback.
>
> I didn't know about this patch. Now I have tried it but I can't see any
> changes at places that I have provided in my first post. Maybe your
> patch deals with other case.
>
> --
> Best
> _______________________________________________
> mkgmap-dev mailing list
> [hidden email]
> http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Distorted lines

popej
In reply to this post by popej
Hi,

since Garmin started to create OSM maps, we can directly compare
different processing of input data. Please look at railways on both
attached pictures. Mkgmap version (simp-mkg.png) is created with branch
high-prec-coord-r3053.

--
Best regards,
Andrzej

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

simp-mkg.png (56K) Download Attachment
simp-mpc.png (50K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Distorted lines

Steve Ratcliffe

A link to OSM would be useful:

   http://www.openstreetmap.org/way/234118154#map=19/52.24497/21.08463
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Distorted lines

Chris66
In reply to this post by popej
Am 15.02.2014 17:32, schrieb Andrzej Popowski:

> since Garmin started to create OSM maps, we can directly compare
> different processing of input data. Please look at railways on both
> attached pictures. Mkgmap version (simp-mkg.png) is created with branch
> high-prec-coord-r3053.

In order to compare, the same TYP file should be used, because this
also has some effect on how distorted the lines appear.

Chris



_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Distorted lines

Gerd Petermann
In reply to this post by popej
Hi Andrzej,

thanks for the hint. This is a good reason for optimizing non-routable
ways as well, which is not yet done.

Gerd

popej wrote
Hi,

since Garmin started to create OSM maps, we can directly compare
different processing of input data. Please look at railways on both
attached pictures. Mkgmap version (simp-mkg.png) is created with branch
high-prec-coord-r3053.

--
Best regards,
Andrzej

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

simp-mkg.png (56K) <http://gis.19327.n5.nabble.com/attachment/5796455/0/simp-mkg.png>
simp-mpc.png (50K) <http://gis.19327.n5.nabble.com/attachment/5796455/1/simp-mpc.png>
Reply | Threaded
Open this post in threaded view
|

Re: Distorted lines

Gerd Petermann
In reply to this post by popej
Hi Andrzej,

I've added the code to optimize non-routable ways in r3059.
Your example looks much better now.

Gerd

Date: Sat, 15 Feb 2014 17:32:23 +0100
From: [hidden email]
To: [hidden email]
Subject: Re: [mkgmap-dev] Distorted lines

Hi,

since Garmin started to create OSM maps, we can directly compare
different processing of input data. Please look at railways on both
attached pictures. Mkgmap version (simp-mkg.png) is created with branch
high-prec-coord-r3053.

--
Best regards,
Andrzej

_______________________________________________ mkgmap-dev mailing list [hidden email] http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Distorted lines

popej
Hi Gerd,

 > I've added the code to optimize non-routable ways in r3059.
 > Your example looks much better now.

That was fast. Result is much better, thanks!

Can we fine-tune effect using option --reduce-point-density?

Some observation:

Map size seems to be nearly 10% less, compared to latest release r3057.

I get many warnings like this:
SEVERE (WrongAngleFixer): pbf\29487111.osm.pbf: non-routable way
101876024 was removed

And some like this:
SEVERE (WrongAngleFixer): pbf\29487111.osm.pbf: Removing wrong angles -
didn't finish in 10 passes, giving up!

There is difference in processing of non-routable lines and polygons,
now outline of a building doesn't match polygon shape. I guess one
change leads to another and probably would be good to apply your updates
to processing polygons too.

--
Best regards,
Andrzej
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Distorted lines

Gerd Petermann
Hi Andrzej,

>
> That was fast. Result is much better, thanks!
>
> Can we fine-tune effect using option --reduce-point-density?

no, but maybe I will add parameters for the hard coded threshold values later.
>
> Some observation:
>
> Map size seems to be nearly 10% less, compared to latest release r3057.

yes, that is intended. 

>
> I get many warnings like this:
> SEVERE (WrongAngleFixer): pbf\29487111.osm.pbf: non-routable way
> 101876024 was removed

that is not intended :-(
Please let me know how I can reproduce that.
 
>
> And some like this:
> SEVERE (WrongAngleFixer): pbf\29487111.osm.pbf: Removing wrong angles -
> didn't finish in 10 passes, giving up!
that also should not happen.
Please let me know how I can reproduce that.

>
> There is difference in processing of non-routable lines and polygons,
> now outline of a building doesn't match polygon shape. I guess one
> change leads to another and probably would be good to apply your updates
> to processing polygons too.

Yes, the algorithm for lines is different to that for shapes, and I can't simply
use the same at this moment. I plan a big change later to allow it, but will
not do it in the high-prec-coord branch.

Gerd


_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Distorted lines

Gerd Petermann
Hi Andrzej,

sorry, the 10% smaller size is also not intended, I thought you compared with trunk.

The way 101876024 is an extremely small building, but you seem to map it as a line?
The algo is not prepared for that.

Gerd


From: [hidden email]
To: [hidden email]
Date: Mon, 17 Feb 2014 22:07:28 +0100
Subject: Re: [mkgmap-dev] Distorted lines

Hi Andrzej,

>
> That was fast. Result is much better, thanks!
>
> Can we fine-tune effect using option --reduce-point-density?

no, but maybe I will add parameters for the hard coded threshold values later.
>
> Some observation:
>
> Map size seems to be nearly 10% less, compared to latest release r3057.

yes, that is intended. 

>
> I get many warnings like this:
> SEVERE (WrongAngleFixer): pbf\29487111.osm.pbf: non-routable way
> 101876024 was removed

that is not intended :-(
Please let me know how I can reproduce that.
 
>
> And some like this:
> SEVERE (WrongAngleFixer): pbf\29487111.osm.pbf: Removing wrong angles -
> didn't finish in 10 passes, giving up!
that also should not happen.
Please let me know how I can reproduce that.

>
> There is difference in processing of non-routable lines and polygons,
> now outline of a building doesn't match polygon shape. I guess one
> change leads to another and probably would be good to apply your updates
> to processing polygons too.

Yes, the algorithm for lines is different to that for shapes, and I can't simply
use the same at this moment. I plan a big change later to allow it, but will
not do it in the high-prec-coord branch.

Gerd


_______________________________________________ mkgmap-dev mailing list [hidden email] http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Distorted lines

popej
Hi Gerd,

 > sorry, the 10% smaller size is also not intended, I thought you
 > compared with trunk.

I have compared with trunk, 3057 is current release.

 > The way 101876024 is an extremely small building, but you seem to map
 > it as a line?

Yes, I'm trying to create a light map for car navigation. I hope that
building outlines are as usable as polygons but less taxing to device.

--
Best regards,
Andrzej
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Distorted lines

Gerd Petermann
Hi Andrzej,
> > sorry, the 10% smaller size is also not intended, I thought you
> > compared with trunk.
>
> I have compared with trunk, 3057 is current release.

okay, seems I was too tired yesterday ;-)

>
> > The way 101876024 is an extremely small building, but you seem to map
> > it as a line?
>
> Yes, I'm trying to create a light map for car navigation. I hope that
> building outlines are as usable as polygons but less taxing to device.

hmm, it will require more bytes because the closing point has
to be saved as well, and shape merge filter can't help as well,
but maybe it requires fewer cpu cycles for rendering.

I think for the given example it is okay to remove the way.
That leaves the question why you see "didn't finish in 10 passes, giving up! "
messages.

Gerd



_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Distorted lines

Gerd Petermann
In reply to this post by popej
Hi Andrzej,

I've fixed one serious in the WrongAngleFixer that removed
lines without good reason.
With r3063 I've increased the max. number of passes to 20, as this
doesn't seem to require much more time.
The message "non-routable way xyz was removed" is now
only printed if the original way has different points in map units,
and now it is just a warning.

The algo is still subject to optimization, as it repeats trying
to fix errors where it can't. It is not as simple as the standard
algos like Douglas-Peucker, as it also moves points
to correct angles in favour of positional errors.
Up to now shapes are optimized with a much simpler
algo which doesn't move points .  The complex algo would require
that it knows all points of all merged(!) shapes, and that doesn't
fit well into the current chain of splitting and merging algos.

Gerd


> Date: Mon, 17 Feb 2014 22:54:00 +0100

> From: [hidden email]
> To: [hidden email]
> Subject: Re: [mkgmap-dev] Distorted lines
>
> Hi Gerd,
>
> > sorry, the 10% smaller size is also not intended, I thought you
> > compared with trunk.
>
> I have compared with trunk, 3057 is current release.
>
> > The way 101876024 is an extremely small building, but you seem to map
> > it as a line?
>
> Yes, I'm trying to create a light map for car navigation. I hope that
> building outlines are as usable as polygons but less taxing to device.
>
> --
> Best regards,
> Andrzej
> _______________________________________________
> mkgmap-dev mailing list
> [hidden email]
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Distorted lines

Chris66
In reply to this post by Gerd Petermann
Am 17.02.2014 10:12, schrieb Gerd Petermann:

> I've added the code to optimize non-routable ways in r3059.
> Your example looks much better now.
>

Hi Gerd,
I assume it's in the high-precision branch, and not in trunc?

Chris



_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
123