navit-project.org
http://forum.navit-project.org/

Why the special case in point reduction in transform.c?
http://forum.navit-project.org/viewtopic.php?f=14&t=413
Page 1 of 1

Author:  sleske [ 23 Jun 2013, 20:29 ]
Post subject:  Why the special case in point reduction in transform.c?

While refactoring the transformation code in transform.c, I stumbled over a line I do not understand:

In transform() (from transform.c), there is code for point reduction (i.e. not drawing points that are too close together):
Code:
if ( (abs(xc - p[k].x) + abs(yc - p[k].y)) < mindist &&
   (c[i+1].x != c[0].x || c[i+1].y != c[0].y))
continue;

(transform.c, line 492ff in current SVN).
The first line makes sense ("are current point and last point closer together than mindist?"). However, I don't understand the purpose of the second line.
I can see that the second line checks that the next point to be processed (c[i+1]) is not equal to the first point (c[0]). But why is this necessary?

I removed the condition, and did not notice any difference in map rendering.
I also checked where the code came from. It was introduced in rev. 2806. The comment there is "Avoid point reduction of connecting points of multi polygons", which did not help me either.

Author:  Mapmapper [ 26 Sep 2013, 11:26 ]
Post subject:  Re: Why the special case in point reduction in transform.c?

Perhaps, if you have several landuses, wich connect only on one point, there could be a gap.

:!: :!: :!: :!: :!: :!: :!:
:!: ----------- :!:
:!:------- :!:
..... :idea: <-connecting-point
:?:xxxxxx :?:
:?:xxxxxxxxx :?:
:?: :?: :?: :?: :?: :?:

landuse :!: and landuse :?: , connected on one point :idea: .
I think, this case is not so important, that you can see this on the map.
And Multi-Polygon means a number of simple Polygons.

Author:  sleske [ 26 Sep 2013, 20:56 ]
Post subject:  Re: Why the special case in point reduction in transform.c?

Mapmapper wrote:
Perhaps, if you have several landuses, wich connect only on one point, there could be a gap.

[...]


Yes, that would fit the commit comment. However, that's not what the code does. The code does not check that a point is also part of another multipolygon, it checks if the point is the last point of the polygon. So I still don't understand...

Author:  usul [ 26 Sep 2013, 22:43 ]
Post subject:  Re: Why the special case in point reduction in transform.c?

FYI: I suggested a more complex generalisation strategies depending on the kind of polygons (buildings, landuse, roads, networks, ...)
http://trac.navit-project.org/ticket/1139

Author:  Mapmapper [ 26 Sep 2013, 23:58 ]
Post subject:  Re: Why the special case in point reduction in transform.c?

sleske wrote:
Mapmapper wrote:
Perhaps, if you have several landuses, wich connect only on one point, there could be a gap.

[...]


Yes, that would fit the commit comment. However, that's not what the code does. The code does not check that a point is also part of another multipolygon, it checks if the point is the last point of the polygon. So I still don't understand...


That's right. And there will be compared two Real-Numbers on equality, that's usually not a good idea.

Houses:
In 0.5.0 its much better than in older versions. The houses look much better. Yes, only while moving the map, they look a bit strange.

Moving the map is still a bit slow. Or better, the reaction time.
Other maps move only the picture of the map und there is an empty grey area on the former place after dragging, that is filled after a while. The rebuild of the map is unvisible in backround and written on one page - I think - of graphic card. And then you call this ready page to be seen on Screen. GTK and others - I think - has ability to do this command to the graphic card.
Ist very slow, to send every street and landuse particular to the screen via graphic card.
To fill the grey areas at first with a few important streets und bigger landuses look surely better than p.e. the grey areas in Lotus.

P.e. open Navit in a window und look, how fast you can move this window with the map in it.

Page 1 of 1 All times are UTC
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
http://www.phpbb.com/