Opened 5 years ago

Closed 4 years ago

#1050 closed defect/bug (fixed)

Generalisation broken

Reported by: me.yahoo.com/a/8osazsp9onby_vzgih2bn_5vq3i272m.dejjjq--#8352e Owned by: KaZeR
Priority: major Milestone:
Component: core Version: git master
Severity: Keywords: generalisation, , building, houses, polygon
Cc:

Description

The generalisation strategy for buildings and landuse polygons is broken since a long time. Currently buildings appear in low zoom levels as triangles and shapes that doesn't represent the usually orthogonal outline of a building. As it's not an easy task to create an appreciate algorithm for this task, I suggest to display the full detailed buildings only at very high zoom levels and to use landuse areas for a general overview in lower zoom levels

Attachments (5)

navit rostock broken buildings.png (123.7 KB) - added by me.yahoo.com/a/8osazsp9onby_vzgih2bn_5vq3i272m.dejjjq--#8352e 5 years ago.
polygon_optimization_mod.diff (741 bytes) - added by tegzed 5 years ago.
disable polygon simplification for polygons with less than 40 vertices
poly.diff (2.8 KB) - added by tryagain 5 years ago.
Another variant of poly optimization
Rostock_partially_fixed.png (104.9 KB) - added by usul 4 years ago.
static rendering llooks ok
Rostock_moving.png (123.4 KB) - added by usul 4 years ago.
while moving the old behaviour comes back

Download all attachments as: .zip

Change History (12)

Changed 5 years ago by me.yahoo.com/a/8osazsp9onby_vzgih2bn_5vq3i272m.dejjjq--#8352e

Changed 5 years ago by tegzed

disable polygon simplification for polygons with less than 40 vertices

comment:1 Changed 5 years ago by tegzed

Hi,

You can configure the zoom levels for each map item type. Check the itemgra entries in your navit.xml .

For this problem I use a little modification in graphics.c (see the attached polygon_optimization_mod.diff ) This patch applies polygon simplification (which causes this triangle effect) only for polygons with more than 40 vertices. If you find it useful I can commit this to svn.

Changed 5 years ago by tryagain

Another variant of poly optimization

comment:2 Changed 5 years ago by tryagain

Hi!

I think the idea behind transform() mindist parameter is to skip unnecessary details from being rendered. Mindist is expressed in projection-dependent units and is compared to value derived from current zoom level. Quite hard to spell and understand.

But if you skip polygons/polylines having less than 40 points from optimization, you'll get performance degradation on slow platforms as navit will always try to render nearly all polys without a change.

Attached poly.diff uses different approach: it makes mindist parameter to be treated as pixel size of the segment. Then segments shorter than two pixels are skipped. Segments shorter than 15 pixels are skipped while the map is being dragged so we have higher framerate and rough geometry approximation.

comment:3 Changed 5 years ago by tegzed

Hi Tryagain!

I guess your solution makes more sense since it is projection independent. However I will only be able to test your patch on the weekend. One little remark on flag handling (not just in this patch but also in other parts of navit code): I think using symbolic names for the flag bits would improve readability a lot and save a lot of time for developers. I will leave a comment here when I had the chance to test it.

comment:4 Changed 5 years ago by tryagain

  • Resolution set to fixed
  • Status changed from new to closed

The patch is applied in r5178

Changed 4 years ago by usul

static rendering llooks ok

Changed 4 years ago by usul

while moving the old behaviour comes back

comment:5 Changed 4 years ago by usul

  • Resolution fixed deleted
  • Status changed from closed to reopened

Thanks for the bugfix (I guess I was the commiting user long time ago)

I can confirm, that this patch solves the problem (at least what I tested) static rendering llooks ok

But the old behaviour still occurs, when you pan the view and keep the mouse pressed. So somewhat what touch devices work like: while moving the old behaviour comes back

comment:6 Changed 4 years ago by sleske

Actually, the current behaviour is by design. The generalization is more aggressive when the map is panned. This is in graphics.s, function "graphics_displaylist_draw":

displaylist->dc.mindist=flags&512?15:2;

Flag 512 means we are currently panning; so during panning the generalization threshhold is increased from 2 pixels to 15. This code was introduced my mdankov in the rev. 5178 (also mentioned above).

I don't know why this is done, but I suppose it is to make drawing faster during panning, to avoid high CPU load and lag on slow devices.

comment:7 Changed 4 years ago by sleske

  • Resolution set to fixed
  • Status changed from reopened to closed

Since this behavior is by design, I'm closing this ticket. If you think the the behavior during panning should be changed, please open a new ticket, since this is a different problem than the one the ticket was opened about.

If you are curious, you could set mindist to be always 2 (by changing the line I indicated above), and test whether performance suffers during panning. If not, then maybe we do not need the higher threshhold during panning...

Note: See TracTickets for help on using tickets.