- mkgmap-dev - The mkgmap lists

filters for shapes
by GerdP 06 Feb '13

06 Feb '13

Hi, the current filter chain for shapes is a bit confusing for me: - We start with PreserveHorizontalAndVerticalLinesFilter which uses the original coords (in map units) to preserve endpoints of vertical and horizontal lines. - Next we use the RoundCoordsFilter which rounds the coords according to the desired resolution For low resolutions, many small shapes are rounded to a single point. Only when the remaining line has at least two points we continue either with the SizeFilter or with the DouglasPeuckerFilter (if they are not disabled) Only the DouglasPeuckerFilter cares about the preserved flag, so I think the PreserveHorizontalAndVerticalLinesFilter should be moved directly before it so that it checks only the rounded coords. I also wonder why we use the PreserveHorizontalAndVerticalLinesFilter for lines that are not shapes. The filter was added with a comment regarding polygons only. Ciao, Gerd -- View this message in context: http://gis.19327.n5.nabble.com/filters-for-shapes-tp5748328.html Sent from the Mkgmap Development mailing list archive at Nabble.com.

1 0

[PATCH v1] Improve aspect ratio of cuttings in multipolygon algorithm
by WanMil 06 Feb '13

06 Feb '13

The patch improves the existing multipolygon cut algorithm. It prefers cuttings with a higher aspect ratio. This avoids very long and small width cuts. That lead to white lines in the precompiled sea areas. With the new algorithm I only saw very few of the white lines but small islands tends to grow when zooming out. The patch fixes precompiling sea and common multipolygons. You have to reprecompile the sea with the patch applied to see a difference. WanMil

2 1

Commit: r2476: Correct and simplify map filter chain: Replaced obsolete LayerFilterChain.addElement() by LayerFilterChain.doFilter() and made sure that all following filters are executed (not only the last)
by svn commit 06 Feb '13

06 Feb '13

Version 2476 was committed by gerd on Wed, 06 Feb 2013 Correct and simplify map filter chain: Replaced obsolete LayerFilterChain.addElement() by LayerFilterChain.doFilter() and made sure that all following filters are executed (not only the last) This error did not cause any harm until r2474.

1 0

Commit: r2475: Fix routing problems introduced with r2448.
by svn commit 06 Feb '13

06 Feb '13

Version 2475 was committed by gerd on Wed, 06 Feb 2013 Fix routing problems introduced with r2448. 1) StyledConverter: try to avoid adding consecutive equal coordinates 2) LinePreparerFilter: do the same calculations as LinePreparer and reject lines that would be rejected later by LinePreparer 3) LineSplitterFilter: don't create small final part which is likely to be discarded

1 0

Patch v2 for routing problems in r2448 and higher
by GerdP 05 Feb '13

05 Feb '13

Hi, attached is a patch that adds a new filter and a simple check to avoid the routine problems. 1) StyledConverter: try to avoid adding consecutive equal coords 2) LinePreparerFilter: do the same calcs as LinePreparer and reject lines that would be rejected later by LinePreparer 3) LineSplitterFilter: don't create small final part which is likely to be discarded fix_routing_v2.patch <http://gis.19327.n5.nabble.com/file/n5748091/fix_routing_v2.patch> It solved the problems reported by NetCheck with my test data but it is still possible that invalid lines are passed to MapBuilder.ShapeAddFilter due to the bogus addElement function. I am not 100% sure if these invalid shapes can cause routing errors, but I doubt it. Ciao, Gerd -- View this message in context: http://gis.19327.n5.nabble.com/Patch-v2-for-routing-problems-in-r2448-and-h… Sent from the Mkgmap Development mailing list archive at Nabble.com.

3 14

[PATCH v1] Ensure that only 0xc bits can be configured with poiDispFlags in LocatorConfig.xml
by WanMil 05 Feb '13

05 Feb '13

The patch ensures that only bits 0x02 and 0x04 are taken from poiDispFlag attribute in the LocatorConfig. Does no longer overwrite the poiDispFlag in the TREHeader but performs an OR with the existing flags. WanMil

1 0

Question reg. LayerFilterChain.addElement
by GerdP 05 Feb '13

05 Feb '13

Hi, maybe I found an error, maybe my understanding is wrong... I thought that all filters in the chain are executed before any element is finally passed to eg. the MapBuilder.LineAddFilter.LineAddFilter But if eg. the LineSplitterFilter calls addElement() instead of doFilter() all following filters are skipped and MapBuilder.LineAddFilter.LineAddFilter is called directly. If this is intended, where should a filter that checks for equal coordinates be placed? I wanted to add it after RemoveEmpty(), but then some invalid lines are passed to the map.addMapObject() method. ciao, Gerd -- View this message in context: http://gis.19327.n5.nabble.com/Question-reg-LayerFilterChain-addElement-tp5… Sent from the Mkgmap Development mailing list archive at Nabble.com.

2 4

Question reg. LinePreparer
by GerdP 05 Feb '13

05 Feb '13

Hi, I simply copied it to the LinePreparerFilter, but what is the idea behind this code in LinePreparer? // compute normalized differences // -2^(shift-1) <= dx, dy < 2^(shift-1) // XXX: relies on the fact that java integers are 32 bit signed final int offset = 8+shift; int dx = (lon - lastLong) << offset >> offset; int dy = (lat - lastLat) << offset >> offset; I don't understand the comment. Why are the values shifted left and right? While debugging I did not see a case where this changed the result. Gerd -- View this message in context: http://gis.19327.n5.nabble.com/Question-reg-LinePreparer-tp5748142.html Sent from the Mkgmap Development mailing list archive at Nabble.com.

2 2

Commit: r2474: Fix typo: supportsNode --> supportsRelation
by svn commit 04 Feb '13

04 Feb '13

Version 2474 was committed by steve on Mon, 04 Feb 2013 Fix typo: supportsNode --> supportsRelation

1 0

Patch for routing problems in r2448 and higher
by GerdP 04 Feb '13

04 Feb '13

Hi, with r2448 the removeShortArcs routine was no longer applied to non-routable ways. This increased the possibility that an invalid line passes all filters but finally is not written to the RGN file while still increasing the subdivision lineNumber. This breaks routing in some case. Attached patch adds a check to the final filter to avoid that. fix_routing_v1.patch <http://gis.19327.n5.nabble.com/file/n5747979/fix_routing_v1.patch> @Steve: It would also be possible to create a new filter for that, but this would mean that we duplicate most of the code in LinePreparer. I don't know if this would be better. Ciao, Gerd -- View this message in context: http://gis.19327.n5.nabble.com/Patch-for-routing-problems-in-r2448-and-high… Sent from the Mkgmap Development mailing list archive at Nabble.com.

4 16