Re: [mkgmap-dev] Option to output polygons in size order

a pond and also more > sand( bunkers ), I am not sure what the relationships on OSM are > meant to be, but from what I have seen that is where most of the > problems lie, it is a lack of that consistent approach that causes > the problems, > > Regards > > Gar

Re: [mkgmap-dev] Option to output polygons in size order

; > golf course there are bunkers, also a lake and in the middle of the > > lake is an island which has a wood on it, and a pond and also more > > sand( bunkers ), I am not sure what the relationships on OSM are > > meant to be, but from what I have seen that is where most o

[mkgmap-dev] Large polygons and subdivisions

ut in an adjacent subdivision the small areas are overwritten. Shouldn't polygons be split on subdivision boundaries? I can't see any code that does this. Regards Ticker Berkin ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http:/

Re: [mkgmap-dev] Large polygons and subdivisions

rs like them, too. > > Gerd > > Von: Ticker Berkin > Gesendet: Samstag, 10. September 2016 17:31 > An: Gerd Petermann > Betreff: Re: AW: [mkgmap-dev] Large polygons and subdivisions > > Hi Gerd > > I've done this and haven't found any side effe

[mkgmap-dev] AllElements patch

of the area. Can this be applied to the main development line? Regards Ticker Berkin Index: src/uk/me/parabola/mkgmap/reader/test/AllElements.java === --- src/uk/me/parabola/mkgmap/reader/test/AllElements.java (revision 3695) +++ src

[mkgmap-dev] patch to write polygons in decreasing order

cross subdivision and map boundaries. All this is controlled by the option --order-by-decreasing-area, with a default of false that leaves the behavior of mkgmap unchanged. A s such, I think this patch could be applied to the trunk development. Regards Ticker Berkin mk Index: doc/option

Re: [mkgmap-dev] AllElements patch

0700, Gerd Petermann wrote: > Hi Ticker, > > I am not sure if I understood the wanted effect, I assume it is not > visible > as well in Basecamp/Mapsource ? > With names you meant the type+subtype labels? > > Gerd > > > Ticker Berkin wrote > >

Re: [mkgmap-dev] patch to write polygons in decreasing order

ile with the patch > 2) MultPpolygonRelation.java contains dead (?) code and uses Long > instead > of long. > Please check my changes in the attached modified patch: > > sortAreas_v2.patch > <http://gis.19327.n8.nabble.com/file/n5884759/sortAreas_v2.patch>  ; > > C

Re: [mkgmap-dev] patch to write polygons in decreasing order

I maintain that there isn't a universal _draworder that will render a map from OpenStreetMap data on the Garmin device in a similar way to how it is shown by www.openStreetMap.org - there are so many examples of nested areas of pasture, woods, grass, playgrounds, etc in any order of overlaying. Yo

Re: [mkgmap-dev] patch to write polygons in decreasing order

ting TYP. > > Remember: All these recent devices need maps without TYP: > https://buy.garmin.com/en-US/US/cOnTheWater-c519-p1.html > Currently it is even very problematic to draw just simple buildings > on those devices. Not to mention water depth areas or intertidal > z

Re: [mkgmap-dev] patch to write polygons in decreasing order

ad and maybe it should go on the enhancement list Regards Ticker On Sat, 2016-10-22 at 14:00 +0100, Ticker Berkin wrote: > Hi Gerd > > I've reproduced the crash. > > I think the problem is that area.getEstimatedSizes() (called from > MapSplitter.addAreasToList) doesn&#

Re: [mkgmap-dev] patch to write polygons in decreasing order

Hi Gerd I've been looking at ShapeSplitter and clipping to a rectangle algorithms generally. I don't feel I know enough about how to use the java.awt.geom package to implement this effectively, and so I'd rather keep to using Java2DConverter and .intersect(), even though it is most likely much les

Re: [mkgmap-dev] patch to write polygons in decreasing order

e the result will be null. > BTW: It seems that this change in the code no longer depends on the > new > option. > Is that intended? > > Gerd > > > > Ticker Berkin wrote > > Hi Gerd > > > > I've been looking at ShapeSplitter and clipp

Re: [mkgmap-dev] patch to write polygons in decreasing order

polygons are written > before > others, no matter how large they are? > This seems to duplicate the code for mkgmap:skipSizeFilter which is > also a > bit dirty. Maybe > > I fully agree that the current data flow for shapes is not good, so > also the > item "rewr

Re: [mkgmap-dev] patch to write polygons in decreasing order

t; merges buildings or forests with the same attributes. > I would assume that this is still a good idea, but you have to > maintain the fullArea value. > Use the attached input file and compare the shapes of the buildings. > > Gerd > > Von: Ticker Berkin > Gesende

Re: [mkgmap-dev] patch to write polygons in decreasing order

Hi Gerd I'll check on the rounding, fix the warn>debug and add the pre-test to the splitting into areas. I've just loaded GPSMapEdit and see what you mean about the long lines of buildings - they are wavy!. I'll work out why it is happening. Regards Ticker On Fri, 2016-11-11 at 01:25 -0700, G

Re: [mkgmap-dev] patch to write polygons in decreasing order

up to the next power of 2. I've improved the javaDoc text for roundPof2. I've made the other changes and attach a patch. Regards Ticker On Fri, 2016-11-11 at 11:37 +, Ticker Berkin wrote: > Hi Gerd > > I'll check on the rounding, fix the warn>debug and add t

Re: [mkgmap-dev] Commit r3702: sortAreas_v5.patch: Add option--order-by-decreasing-area

evice that doesn't support TYP/_draworder? Maybe it has inbuild _draworder that can't be overridden or there is some subtlety about what is shown. Ticker Berkin On Sat, 2016-11-12 at 20:48 +0100, rheinskipper1...@gmx.de wrote: > I eagerly awaited the order-by-decreasing-area option. &

Re: [mkgmap-dev] Commit r3702: sortAreas_v5.patch: Add option --order-by-decreasing-area

more correct > So probably makes sense to deactivate it on devices with typ > draworder? > Best > Jakob > Am 11.11.2016 um 17:11 schrieb svn commit: > > Version mkgmap-r3702 was committed by gerd on Fri, 11 Nov 2016 > > > > sortAreas_v5.patch: Add option --ord

Re: [mkgmap-dev] Commit r3702: sortAreas_v5.patch: Addoption--order-by-decreasing-area

> > aebWc > > > > > > > > > > > > Von: svn commit > > > Gesendet: Freitag, 11. November 2016 17:11 > > > An: > > > > > mkgmap-svn@.org > > > > > ; > > > > > mkgmap-dev@.org > > >

[mkgmap-dev] mkgmap:drawLevel and --order-by-decreasing-area

Here is a patch that implements mkgmap:drawLevel It is used in conjunction with --order-by-decreasing-area and overrides the natural polygon area that is used for output sorting, hence influencing which polygons are rendered over others. The higher the value, the later the polygon is written and

Re: [mkgmap-dev] mkgmap:drawLevel and --order-by-decreasing-area

Hi Andrzej I've tested it on my Garmin Etrex Legend. As I said, it needs a TYP file giving equal _drawOrder to almost everything - except I forgot to mention that I think the in-build behavior of the Legend for Sea/0x32 is to show it on top, but this is fixed by TYP/_drawOrder, behaving as expecte

Re: [mkgmap-dev] Spurious points & Basecamp blank tiles

Hi Not quite, you should have something like: seamark:type=fairway {name 'fairway'; set mkgmap:drawLevel=60 } [0x10306 level 2] waterway=riverbank { set mkgmap:drawLevel=02 } [0x10302 resolution 18] but you only need one of the mkgmap:drawLevel for the fairway to be written after/overwrite the r

Re: [mkgmap-dev] mkgmap:drawLevel and --order-by-decreasing-area

Hi Gerd The messing with the area happens after style processing so doesn't effect the result of the area_size() function. Ticker On Wed, 2016-11-16 at 23:00 -0700, Gerd Petermann wrote: > Hi all, > > Ticker Berkin wrote > > It is used in conjunction with --order-by

Re: [mkgmap-dev] mkgmap:drawLevel and --order-by-decreasing-area

pes for water depth which all have > same built in draw order. Now chances are good that they can be > controlled. > > > > And sorry for mixing LEVEL and RESOLUTION. I used LEVEL but my style > is based on default style which uses RESOLUTION. > > > Ups, threa

Re: [mkgmap-dev] mkgmap:drawLevel and --order-by-decreasing-area

Your right - it is big. My system didn't want to download it without installing some add-ons which I don't want to do at the moment. However, I have reproduced the same diagnostic from one of my maps and am investigating that. It is more related to --order-by-.. than mkgmap:drawLevel and the bound

Re: [mkgmap-dev] mkgmap:drawLevel and --order-by-decreasing-area

Level patch Ticker On Sat, 2016-11-19 at 10:46 +0000, Ticker Berkin wrote: > Your right - it is big. My system didn't want to download it without > installing some add-ons which I don't want to do at the moment. > > However, I have reproduced the same diagnostic fro

Re: [mkgmap-dev] mkgmap:drawLevel and --order-by-decreasing-area

ks for the patch. I was not yet able to reproduce the problem > reported by rheinskipper1000. Do you have a test case for me? > > Gerd > Von: mkgmap-dev im Auftrag > von Ticker Berkin > Gesendet: Mittwoch, 23. November 2016 13:39:16 > An: mkgmap-dev@lists.mkgmap.org.uk > Be

Re: [mkgmap-dev] mkgmap:drawLevel and --order-by-decreasing-area

t; reproduce it with only one tile > and post a link to the needed package. > > Gerd > > > Von: Ticker Berkin > Gesendet: Donnerstag, 24. November 2016 12:25 > An: mkgmap-dev@lists.mkgmap.org.uk > Betreff: Re: [mkgmap-dev] mkgmap:drawLevel and --order-by-decreasing &g

Re: [mkgmap-dev] mkgmap:drawLevel and --order-by-decreasing-area

Hi Gerd, Just noticed that you didn't include the change to resources/styles/default/inc/water_polygons that was in drawLevel_v2.patch -natural=sea { add mkgmap:skipSizeFilter=true } [0x32 resolution 10] +natural=sea { add mkgmap:skipSizeFilter=true; set mkgmap:drawLevel=2 } [0x32 resolution 10]

Re: [mkgmap-dev] mkgmap:drawLevel and --order-by-decreasing-area

Hi Gerd No - this was the only occurrence. Ticker On Mon, 2016-11-28 at 02:38 -0700, Gerd Petermann wrote: > Hi Ticker, > > this was not intended, I mixed my own tests with your patch. > Did you try to use mkgmap:drawLevel for other polygons, e.g. > buildings? > > Ge

Re: [mkgmap-dev] mkgmap:drawLevel and --order-by-decreasing-area

Hi Gerd No, it shouldn't make any difference. It was more like documentation and a pointer to where the tag was used and could be changed. But I wasn't sure about all the ways sea polygons could come into being and so having this ensured the same area was always set. It also matches a comment in S

Re: [mkgmap-dev] Problem with r3706

I'll have a look. I didn't intentionally change extended type behaviour, but shapes will end up in different subdivisions with the option applied Ticker On Fri, 2016-12-02 at 07:09 -0700, Gerd Petermann wrote: > I've got some more test data from Arndt, I've reproduced the > assertion, here > is

Re: [mkgmap-dev] Attributes

Hi I was looking at this area in the code yesterday for some other problem and spotted this big comment: /* Add support for extended type attributes. These are nearly all for marine objects. Attribute values are supplied as tags with a mkgmap:xt- prefix. These tags are supported: mkgmap:xt-dept

Re: [mkgmap-dev] Problem with r3706

On Fri, 2016-12-02 at 15:49 +0100, Arndt Röhrig wrote: > Hi, > Thank you all for the support! > > Best regaards > > Ticker Berkin hat am 2. Dezember 2016 um > 15:22 geschrieben: > > > I'll have a look. I didn't intentionally change extended type >

Re: [mkgmap-dev] Attributes

Looking at the code/comment (I have no expertise whatsoever in these extended attributes): Try mkgmap:xt-style to set line attributes (style and colour). mkgmap:xt-colour takes a colour name and looks as if it is only applicable to buoys. you can also supply a raw byte string as hex characters

Re: [mkgmap-dev] MapFailedExceptions with mkgmap-r3706

Hi Gerd Yes - looks good. I think the old code would have quietly underflowed when doing getWidth()/getHeight() on the empty area, resulting in a value of 1 (Integer.MIN_VALUE - Integer.MAX_VALUE) Ticker On Thu, 2016-12-15 at 18:53 +, Gerd Petermann wrote: > Hi Steph, > > your style produce

Re: [mkgmap-dev] Minimum resolution in polygons style

Seems like a good idea - It should use the --polygon-size-limits option in an inverted sort of way. Ticker On Wed, 2016-12-21 at 07:48 +, Gerd Petermann wrote: > Hi all, > > while debugging the problem reported by Arndt Röhrig > http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2016q4/025471.htm

Re: [mkgmap-dev] Minimum resolution in polygons style

AtRes24 much earlier. > > Gerd > > > > > > > > > > > Von: mkgmap-dev im Auftrag > von Ticker Berkin > Gesendet: Mittwoch, 21. Dezember 2016 13:23:17 > An: mkgmap-dev@lists.mkgmap.org.uk > Betr

[mkgmap-dev] New code for splitting polygon

ShapeSplitter.java (working copy) @@ -18,6 +18,14 @@ import java.awt.geom.Rectangle2D; import java.util.Arrays; +// RWB new bits +import java.util.ArrayList; +import java.util.List; +import it.unimi.dsi.fastutil.longs.Long2ObjectOpenHashMap; +import uk.me.parabola.imgfmt.Utils; +import uk.m

Re: [mkgmap-dev] New code for splitting polygon

t line > and one or more line segments on the split line? > > Gerd > > Von: mkgmap-dev im Auftrag > von Ticker Berkin > Gesendet: Samstag, 7. Januar 2017 18:36:31 > An: mkgmap development > Betreff: [mkgmap-dev] New code for s

Re: [mkgmap-dev] New code for splitting polygon

s an example. > And sorry, I should already have coded one for > clipSinglePathWithSutherlandHodgman(). > > Gerd > > > > Von: mkgmap-dev im Auftrag > von Ticker Berkin > Gesendet: Sonntag, 8. Januar 2017 11:20:19 > An:

Re: [mkgmap-dev] New code for splitting polygon

a closer look today. I found some cases where the patched > version produces different results, > not yet sure which is better. I did not find a test case with an > unconnected hole. Is the algo prepared for that, too? > > Gerd > > >

Re: [mkgmap-dev] new branch split-shape

Hi Gerd I've fetched this branch, applied my changes and added the new code, changed the indention (need to work out how to change the Java mode for my editor to this style). Then [ticker@jag11 split-shape]$ svn commit -m "New ShapeSplitter algorithm + unit test" Authentication realm:

Re: [mkgmap-dev] new branch split-shape

ur own branch, not sure if you > can update one that I've created. > > Gerd > > ____ > Von: mkgmap-dev im Auftrag > von Ticker Berkin > Gesendet: Donnerstag, 12. Januar 2017 16:43:50 > An: mkgmap-dev@lists.mkgmap.org.uk > Bet

Re: [mkgmap-dev] new branch split-shape

mann wrote: > Hi Ticker, > > Ticker Berkin wrote > > Steve changed some stuff and I've now been able to commit it to the > > branch. > > I tested with a map for germany and got some error messages. > I used this command: > java -Xmx6G -jar d:\mkgmap-split-sha

Re: [mkgmap-dev] [Patch] "Area too small to split at " ... followed by "Too many POIs at location " error message

Hi Gerd Yes; however, regardless of useNormalSplit, with --order-by... the shapes need to be split into their correct area. This bit of code has always troubled me. I wasn't sure if its objective was to lessen the chance of empty subdivisions or to lessen the chance of exceeding maximum data size

Re: [mkgmap-dev] [Patch] "Area too small to split at " ... followed by "Too many POIs at location " error message

ing the same center point. > At that time I tried to minimize the possibility that this code is > executed in other cases. > However, it seems that this is dead code since r3351 because of the > handling with largeObjectAreas. > I think I should remove it. > > Gerd > > >

Re: [mkgmap-dev] new branch split-shape

eas.list) > > Gerd > > > Von: mkgmap-dev im Auftrag > von Ticker Berkin > Gesendet: Freitag, 13. Januar 2017 09:54:01 > An: mkgmap-dev@lists.mkgmap.org.uk > Betreff: Re: [mkgmap-dev] new branch split-shape > > Hi Gerd > > I thought this case would never h

Re: [mkgmap-dev] new branch split-shape

> Von: mkgmap-dev im Auftrag > von Ticker Berkin > Gesendet: Freitag, 20. Januar 2017 16:54:16 > An: mkgmap-dev@lists.mkgmap.org.uk > Betreff: Re: [mkgmap-dev] new branch split-shape > > Hi Gerd > > I've fixed ShapeSplitter and committed it to branches/split-

Re: [mkgmap-dev] new branch split-shape

ning > with "rewrite classes that hold" > http://www.mkgmap.org.uk/dev/todo > esp. the part regarding "merge shapes before splitting the map into > sub areas" > > Do you think that this would also work with the --order-by-decreasing > -area option? > > Gerd &g

Re: [mkgmap-dev] Multipolygon-Relation checks in mkgmap

Hi Gerd Yes - please I started looking at MultiPolygonRelation yesterday with a view of trying to convert it to use the new ShapeSplitter algorithm. I think that the way a self-intersecting polygon is rewritten after a split using the Java2D library causes problems for the new algorithm when it

Re: [mkgmap-dev] Multipolygon-Relation checks in mkgmap

points after the split complains and plot them it shows an overlap. Ticker On Wed, 2017-01-25 at 14:29 +, Gerd Petermann wrote: > Hi Ticker, > > do you have an example for such a problem case? > > Gerd > > > Von: mkgmap-dev

Re: [mkgmap-dev] new branch split-shape

ap-dev im Auftrag > von Gerd Petermann > Gesendet: Montag, 23. Januar 2017 11:01:11 > An: mkgmap-dev@lists.mkgmap.org.uk > Betreff: Re: [mkgmap-dev] new branch split-shape > > Hi Ticker, > > Ticker Berkin wrote > > What aspect of sea polygons is getting worse? >

Re: [mkgmap-dev] Multipolygon-Relation checks in mkgmap

openstreetmap.org/relation/2199651 > is solved with r3773, but your case looks different. > > Gerd > > ____ > Von: mkgmap-dev im Auftrag > von Ticker Berkin > Gesendet: Mittwoch, 25. Januar 2017 15:56:06 > An: mkgmap-dev@lists.mkgma

Re: [mkgmap-dev] Multipolygon-Relation checks in mkgmap

plit, and try again." > > Gerd > > ____ > Von: mkgmap-dev im Auftrag > von Ticker Berkin > Gesendet: Donnerstag, 26. Januar 2017 11:40:09 > An: mkgmap-dev@lists.mkgmap.org.uk > Betreff: Re: [mkgmap-dev] Multipolygon-Relation checks in mkgmap &

[mkgmap-dev] Limit I don't understand in subDiv split filters

Hi Gerd LineSizeSplitterFilter and PolygonSubdivSizeSplitterFilter both contain the logic: public static final int MAX_SIZE = 0x7fff; ... maxSize = Math.min((1<<24)-1, Math.max(MAX_SIZE << shift, 0x8000)); and then maxSize is used to limit the standard Area bounds of the item. Won't this will

Re: [mkgmap-dev] Multipolygon-Relation checks in mkgmap

Hi Gerd I've just committed something to split polygons early at high precision. It has become a work-in-progress to stop needless area splitting at low resolutions; hence I've left in comments and thoughts to myself that I'll gradually tidy up. Ticker __

Re: [mkgmap-dev] Multipolygon-Relation checks in mkgmap

. > > In other places it seems to improve things, e.g. the soccer field > near 48.906100 13.460832 > no longer disappears at level 1. > > Gerd > > ________ > Von: mkgmap-dev im Auftrag > von Ticker Berkin > Gesendet: Freita

Re: [mkgmap-dev] Multipolygon-Relation checks in mkgmap

Hi Gerd I've just committed another batch of changes. It is getting close to being finished but not quite there yet and still doesn't solve the 1/2 park issue but I will address this soon. Ticker On Sat, 2017-01-28 at 11:07 +0000, Ticker Berkin wrote: > Hi Gerd > >

Re: [mkgmap-dev] Multipolygon-Relation checks in mkgmap

Hi Gerd I've think I've finished making all the changes I want to do at the moment - It seems to work nicely. Sometime can you merge the branch back if you are happy with it. Thanks Ticker ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk ht

Re: [mkgmap-dev] Multipolygon-Relation checks in mkgmap

ched is a patch with what I coded so far, open problems > are mp-rels at tile boundaries and performance. Be careful, the code > contains lots of GPXCreator statements and other debug code. > > Gerd > > ____ > Von: mkgmap-dev im Au

Re: [mkgmap-dev] Problems with r3781

Hi Gerd I'l check this out Ticker On Wed, 2017-02-01 at 09:11 +, Gerd Petermann wrote: > Hi Ticker, > > I see some error messages when creating a map for northwest > -territories-latest.osm.pbf: > SCHW: uk.me.parabola.imgfmt.app.trergn.Polyline > e:\osm_out_work\northwest > -territories\2

Re: [mkgmap-dev] Multipolygon-Relation checks in mkgmap

at means that java area code also > doesn't care. > Anyhow, I think that problem is solved with the reversing. > > I am running further tests with r3781 rnow. > > Gerd > ________ > Von: mkgmap-dev im Auftrag > von Ticker Berkin

Re: [mkgmap-dev] Problems with r3781

Hi Gerd Sorry - I wasn't paying attention and missed the vital bit of your mail: northwest-territories-latest.osm.pbf Will try with the correct file! Ticker On Wed, 2017-02-01 at 10:17 +0000, Ticker Berkin wrote: > Hi Gerd > > Using your new areas.list file and > Spl

Re: [mkgmap-dev] Problems with r3781

Hi Gerd I'l check this out Ticker On Wed, 2017-02-01 at 09:11 +, Gerd Petermann wrote: > Hi Ticker, > > I see some error messages when creating a map for northwest > -territories-latest.osm.pbf: > SCHW: uk.me.parabola.imgfmt.app.trergn.Polyline > e:\osm_out_work\northwest > -territories\2

Re: [mkgmap-dev] Problems with r3781

2017-02-01 at 09:17 +0000, Ticker Berkin wrote: > Hi Gerd > > I'l check this out > > Ticker > > On Wed, 2017-02-01 at 09:11 +, Gerd Petermann wrote: > > Hi Ticker, > > > > I see some error messages when creating a map for no

Re: [mkgmap-dev] WG: Please help

list... > > Gerd > > > Von: Gerd Petermann > Gesendet: Mittwoch, 1. Februar 2017 16:09 > An: Ticker Berkin > Betreff: Please help > > Hi Ticker, > > I try to understand why ShapeSplitter complains about a polygon > created by my new algo. > Attached i

Re: [mkgmap-dev] Problems with r3781

lar needs to be put back Ticker On Wed, 2017-02-01 at 11:32 +, Ticker Berkin wrote: > Hi Gerd > > Sorry - I wasn't paying attention and missed the vital bit of your > mail: northwest-territories-latest.osm.pbf > > Will try with the correct file! > > Ticker >

Re: [mkgmap-dev] WG: Please help

degrees (Latitude as X = horizontal) Ticker On Wed, 2017-02-01 at 16:39 +, Gerd Petermann wrote: > Hi Ticker, > > if diagonal cuts cause problems I can stop this. > > Gerd > > Von: mkgmap-dev im Auftrag > von Ticker Berkin

Re: [mkgmap-dev] Error in branch

Hi Gerd I'll check it out. My bounds.zip (&sea.zip) are quite old so I'll get the latest. Ticker On Fri, 2017-02-03 at 09:11 +, Gerd Petermann wrote: > Hi Ticket, > > I found another problem in the branch which probably was introduced > with r3779 and still exists with r3782: > java.lang.As

Re: [mkgmap-dev] Error in branch

Hi Gerd Interesting - checking adjacent Coord for equality of appropriately powerOf2 rounded highPrec gives different results from equivalent rounding of Map precision values. I've committed fix. Ticker On Fri, 2017-02-03 at 10:31 +0000, Ticker Berkin wrote: > Hi Gerd > > I&#

Re: [mkgmap-dev] r3784 produces large img files than r3773

Hi Gerd Most of the changes that will make a difference to size are related to MapArea/SubDivision contents and splitting hence ShapeMergeFilter activity. As far as changes in size between the versions: 3782-3784 should be similar and a little bit worse than 3781 because of a fix to stop a large

Re: [mkgmap-dev] r3784 produces large img files than r3773

Hi Gerd One of the reasons I went along the PredictPoints route is that MapArea was calculating the subDivision usage (number of items, amount of data) based on totally unfiltered lines/polygons, regardless of the resolution, so this was forcing splits where no need whatsoever. I didn't want to a

Re: [mkgmap-dev] r3784 produces large img files than r3773

Hi Gerd I've done this and committed. In the examples I found, using backtracking to split the polygon gave very slight size improvements (best was about 0.05%) Ticker On Sat, 2017-02-04 at 06:10 -0700, Gerd Petermann wrote: > Hi Ticker, > > Ticker Berkin wrote > > I can

Re: [mkgmap-dev] r3784 produces large img files than r3773

Done On Tue, 2017-02-07 at 12:17 +, Gerd Petermann wrote: > Hi Ticker, > > that's what I expected. Most shapes do not have too many points > after line simplification. > If I got that right most of the code in PolygonSplitterFilter is now > obsolete. I think it would be > better to move the

Re: [mkgmap-dev] r3784 produces large img files than r3773

ngArea as a (final) field in MapSplitter? > > Gerd > > > ________ > Von: mkgmap-dev im Auftrag > von Ticker Berkin > Gesendet: Dienstag, 7. Februar 2017 13:45:25 > An: mkgmap-dev@lists.mkgmap.org.uk > Betreff: Re: [mkgmap-dev] r3784 produces

Re: [mkgmap-dev] r3784 produces large img files than r3773

dex that allows to quickly find nearby > way segments , I will use that to find intersections in mp-rels > in the same way as I've implemented it with some patches for JOSM. > The index might be useful for my cut algo as well. > > Gerd > _______

Re: [mkgmap-dev] r3784 produces large img files than r3773

correct but not good for > further processing. > > Gerd > > Von: mkgmap-dev im Auftrag > von Ticker Berkin > Gesendet: Dienstag, 7. Februar 2017 18:43:43 > An: mkgmap-dev@lists.mkgmap.org.uk > Betreff: Re: [mkgmap-dev] r3784 p

Re: [mkgmap-dev] unit test fails in branch

Fixed this. svn commit comment should have been: "Merge in trunk and cope with mapSource without bounds" Ticker On Wed, 2017-02-08 at 08:46 +, Gerd Petermann wrote: > Hi Ticker, > > please check: > The unit test testCombiningSupps() in class GmapsuppTest fails: > SCHWERWIEGEND (MapFailedE

Re: [mkgmap-dev] unit test fails in branch

t; Source) > at java.lang.Thread.run(Unknown Source) > Exiting - if you want to carry on regardless, use the --keep-going > option > Number of ExitExceptions: 1 > > Gerd > > Von: mkgmap-dev im Auftrag > von Ticker Berkin > Gesendet

Re: [mkgmap-dev] roundabouts

Hi With these default rules, my device (Etrex Legend HCx) renders roundabouts nicely (dark medium line, looks same as 0x04/0x05 line) and has a suitable 'hover' label. No typ file. Ticker On Sun, 2017-02-12 at 11:39 +, Gerd Petermann wrote: > Hi all, > > the default style contains these rul

Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch

Hi Mike This is an area of code I've changed and it should be able to cope with many items at the same location without recursing. Do you have some sample data? what are the items (point/line/shape extended?) Ticker On Tue, 2017-02-14 at 17:40 +, Mike Baggaley wrote: > Hi Gerd, since this c

Re: [mkgmap-dev] Performace mkgmap-3803

Hi Gerd Yes - use the patch Still not sure why there is a change in performance here though. Ticker On Tue, 2017-02-14 at 17:44 +, Gerd Petermann wrote: > Hi Arndt, > > your style is very special because it adds all polygons with > resolution 10. I assume that this is the > reason for this

Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch

splits before crashing, it looks like the splitting is not working - > there won't be more than 2000 * 255 postcodes at the same place. My > OSM file is rather large. I can see whether I can extract a map > centred on a sorting office. > > Regards, > Mike > > -Ori

Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch

oks like the call to > area.split is not actually splitting. Looking at the resulting file > in BaseCamp, I can see that the coastline is corrupt. > > Hope that helps, > Mike > > -Original Message- > From: Ticker Berkin [mailto:rwb-mkg...@jagit.co.uk] > Se

Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch

Hi Gerd / Mike I've just committed a fix for this to the split-shape branch Ticker On Wed, 2017-02-15 at 08:53 +0000, Ticker Berkin wrote: > Hi Mike > > OK - I think I understand the problem. > > Can you try with --order-by-decreasing-area and let me know if that > stop

Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch

Hi Mike I think this is just a problem with the rules the tool you are using to show the image conflicting with what --order-by-decreasing-area aims to achieve on a Garmin device. For instance, observations of GPSMapEdit shows it renders smaller polygons on top of larger ones as the way of decidi

Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch

Hi Mike I'll fix/improve the message. Can you tell if it is the sea polygons, the line 'coastline', or the island area (if your style generates this) that is corrupt. Maybe send your splitter options / areas.list, mkgmap options and style and I'll see if I can reproduce. Ticker On Thu, 2017-02

Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch

r 2017 10:40:55 > An: mkgmap-dev@lists.mkgmap.org.uk > Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch > > HI Ticker, I'll package up some data for you. I have generate > -sea:extend-sea-sectors in my options file, I think it will be > related to that.

Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch

nch into trunk. > Please post some test data to show the coastline problem and I'll try > to fix it. > > Gerd > > Von: mkgmap-dev im Auftrag > von Ticker Berkin > Gesendet: Freitag, 17. Februar 2017 09:50:17 > An: mkgmap-dev@lists.mkgmap.org

Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch

hey cause trouble. > > Gerd > > Von: mkgmap-dev im Auftrag > von Ticker Berkin > Gesendet: Freitag, 17. Februar 2017 10:32:11 > An: mkgmap-dev@lists.mkgmap.org.uk > Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch > > Hi Gerd &

Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch

and tileArea.getBounds() is in Garmin units > > Gerd > ________ > Von: mkgmap-dev im Auftrag > von Ticker Berkin > Gesendet: Freitag, 17. Februar 2017 11:00:49 > An: mkgmap-dev@lists.mkgmap.org.uk > Betreff: Re: [mkgmap-dev] RE Commit r3801: me

Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch

ot see an advantage in using high-prec. Why do you think it > should be used? > > Gerd > > > Von: mkgmap-dev im Auftrag > von Ticker Berkin > Gesendet: Freitag, 17. Februar 2017 13:27:28 > An: mkgmap-dev@lists.mkgmap.org.uk >

Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch

Hi According to my calcs, full 32 bit integers give a resolution of about 10mm at the equator. Why do you need better than existing high-res (30 bits - ~40mm)? Maybe go to 31 to save the +-180 degree problem. Not to have the resolution as a powerOfTwo of the garmin map unit would require a lot o

Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch

> points too far. Anyway, I should fix this first. > > I started to go for 32 bits because some algos which I coded for JOSM > use this res. It seemed easier to change mkgmap to > also use 32 bits, but I am no longer sure about that. > > Gerd > __

Re: [mkgmap-dev] [Patch v1] nwe special tag mkgmap:residential

Hi Gerd For an unrelated reason, I was just comparing logs of a run with trunk (r-3834) with my version which contains up to r-3831 and mix of some of your patches and my changes and, for trunk, for I get 140 or so lines like: WARN: uk.me.parabola.mkgmap.reader.osm.boundary.BoundaryQuadTree 742

Re: [mkgmap-dev] if-then-else in style and style options

Hi I think you should document that you need a dummy condition, ie if (...) then 1=1 {action} ... 1=1 [0x1c ...] end (I assume this should work OK) Ticker On Wed, 2017-03-08 at 08:07 +, Gerd Petermann wrote: > Hi all, > > while writing the documentation I noticed this possible probl

[mkgmap-dev] ShapeMergeFilter bug

Hi Gerd around line 73, it need the addAll (or equivalent) line if (usableShapes.size() < 2) { mergedShapes.addAll(usableShapes); return mergedShapes; } Ticker ___ mkgmap-

Re: [mkgmap-dev] [Patch v1] differet Coord implementation

Hi Gerd Are you still planning to implement this patch. I've been using it for a while with some additional changes and I didn't have any problems. I think it is tidier and makes things more obvious. The addition changes I had were roughly as I listed in a follow-up: ... much clearer and have

<    6   7   8   9   10   11   12   >