s to combine shapes
> > with similar attributes.
> > I still don't understand why the size should matter, but it should
> > be easy to add a sort after the line
> > shapes = mergedShapes;
> > in MapBuilder.java
> >
> > I don't have the time today, so try o
Hi Gerd
If you are changing style, please can you remove:
>> railway=abandoned [0x0a road_class=0 road_speed=1 resolution 22]
from styles/default/lines - there might be no trace of it left, across
private land... and it looks just like a usable track
If there is a track following the old line
; 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
>
> Gary
>
>
> From: mkgm
gons in other sub areas. I assume that the order in
> which these
> sub areas are rendered depends on the direction you are moving.
>
> Gerd
>
> Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag
> von Ticker Berkin <rwb-mkg...@jagit.co.uk>
> Gesend
is about
> rendering a map. So I am not sure if it fits within the mkgmap remit.
>
> Regards
>
> Gary
>
>
>
>
> From: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> on behalf
> of Ticker Berkin <rwb-mkg...@jagit.co.uk>
> Sent: 23 July 2016 1
al solution
Ticker
On Sun, 2016-07-24 at 00:05 -0700, Gerd Petermann wrote:
> Hi Ticker,
>
> Ticker Berkin wrote
> > I'd understood and hoped that, for areas with the same level it
> > rendered areas in file order, and I see on my device it
> > overwriting,
> >
>
> From: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> on behalf
> of Ticker Berkin <tic...@jagit.co.uk>
> Sent: 28 July 2016 16:41
> To: mkgmap-dev@lists.mkgmap.org.uk
> Subject: Re: [mkgmap-dev] Option to output polygons in size order
>
> Hi Gary
>
>
; 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
>
> Gary
>
>
> From: mkgm
gt; the sorting,
> after applying the patch to r3683 see MapBuilder line 1123 and below.
>
> I still want to fix minor problems with the overview map,
> that's why I did not yet publish the patch.
>
> Gerd
> Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im
lygons at this
point.
Regards
Ticker Berkin
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> and I would be surprised when that is true.
> The normal way to handle the draw order is to use a typ file, not
> sure
> if this works on your device, but it seems to work well for others.
>
> Gerd
> Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag
>
> Gary
>
> From: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> on behalf
> of Ticker Berkin <rwb-mkg...@jagit.co.uk>
> Sent: 23 July 2016 18:42
> To: mkgmap-dev@lists.mkgmap.org.uk
> Subject: Re: [mkgmap-dev] Option to output polygons in size order
>
the larger polygon first, but in those cases
> this would not help.
> I think this solution would also not help when polygons partially
> overlap.
>
> Gerd
> Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag
> von Ticker Berkin <rwb-mkg...@jagit.co.uk>
>
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
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
>
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 <mkgmap-dev-boun...@lists.mkgmap.or
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
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
>
-02-01 at 09:17 +, 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 northwest
&g
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 +, Ticker Berkin wrote:
> Hi Gerd
>
> Using your new areas.list file and
> Splitter
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 <mkgmap-dev-boun.
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
a (final) field in MapSplitter?
>
> Gerd
>
>
>
> Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag
> von Ticker Berkin <rwb-mkg...@jagit.co.uk>
> Gesendet: Dienstag, 7. Februar 2017 13:45:25
> An: mkgmap-dev
ev-boun...@lists.mkgmap.org.uk> im Auftrag
> von Ticker Berkin <rwb-mkg...@jagit.co.uk>
> Gesendet: Dienstag, 7. Februar 2017 14:34:36
> An: mkgmap-dev@lists.mkgmap.org.uk
> Betreff: Re: [mkgmap-dev] r3784 produces large img files than r3773
>
> Hi Gerd
>
> orderByDe
t 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 <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag
> von T
ould be correct but not good for
> further processing.
>
> Gerd
>
> Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag
> von Ticker Berkin <rwb-mkg...@jagit.co.uk>
> Gesendet: Dienstag, 7. Februar 2017 18:43:43
&g
..
>
> 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 is a p
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
>
>
> On Wed,
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
Hi Gerd
I'll check it out. My bounds.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:
>
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 +, Ticker Berkin wrote:
> Hi Gerd
>
> I'll che
org.uk> im Auftrag
> von Ticker Berkin <rwb-mkg...@jagit.co.uk>
> Gesendet: Mittwoch, 1. Februar 2017 17:04:36
> An: mkgmap-dev@lists.mkgmap.org.uk
> Betreff: Re: [mkgmap-dev] WG: Please help
>
> Hi Gerd
>
> I've plotted the outer data. Not quite well enough to see a
___
> Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag
> von Ticker Berkin <rwb-mkg...@jagit.co.uk>
> 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
>
rd
>
> ____
> Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag
> von Ticker Berkin <rwb-mkg...@jagit.co.uk>
> Gesendet: Sonntag, 22. Januar 2017 19:23:53
> An: mkgmap-dev@lists.mkgmap.org.uk
> Betreff: Re: [mkgmap-dev] new
and try again."
>
> Gerd
>
>
> Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag
> von Ticker Berkin <rwb-mkg...@jagit.co.uk>
> Gesendet: Donnerstag, 26. Januar 2017 11:40:09
> An: mkgmap-dev@lists.mkgmap.org.uk
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
t; 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 <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag
> von Ticke
map-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag
> von Gerd Petermann <gpetermann_muenc...@hotmail.com>
> 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 B
map-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag
> von Ticker Berkin <rwb-mkg...@jagit.co.uk>
> Gesendet: Mittwoch, 25. Januar 2017 13:25:34
> An: mkgmap-dev@lists.mkgmap.org.uk
> Betreff: Re: [mkgmap-dev] Multipolygon-Relation checks in mkgmap
>
> Hi Gerd
>
>
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
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
rg/relation/2199651
> is solved with r3773, but your case looks different.
>
> Gerd
>
>
> Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag
> von Ticker Berkin <rwb-mkg...@jagit.co.uk>
> Gesendet: Mittw
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 +, Ticker Berkin wrote:
> Hi Gerd
>
> I see thi
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,
; reason. I think one was that the WrongAngleFixer started to move
> 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 a
advantage in using high-prec. Why do you think it
> should be used?
>
> Gerd
>
>
> Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag
> von Ticker Berkin <rwb-mkg...@jagit.co.uk>
> Gesendet: Freita
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
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
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
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
ts 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
>
> -Original Mess
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]
> Sent: 14 February 2
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
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 +, 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
> stops the
trouble.
>
> Gerd
>
> Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag
> von Ticker Berkin <rwb-mkg...@jagit.co.uk>
> Gesendet: Freitag, 17. Februar 2017 10:32:11
> An: mkgmap-dev@lists.mkgmap.org.uk
> Betreff: Re: [mkgmap-
t; Betreff: Re: [mkgmap-dev] RE Commit r3801: merge split-shape branch
>
> Hi Ticker,
>
> okay, I'll merge the branch into trunk.
> Please post some test data to show the coastline problem and I'll try
> to fix it.
>
> Gerd
> _
ions file, I think it will be
> related to that.
>
> Regards,
> Mike
>
> -Original Message-
> From: Ticker Berkin [mailto:rwb-mkg...@jagit.co.uk]
> Sent: 16 February 2017 08:17
> To: mkgmap-dev@lists.mkgmap.org.uk
> Subject: Re: [mkgmap-dev] RE Commi
rea.getBounds() is in Garmin units
>
> Gerd
>
> Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag
> von Ticker Berkin <rwb-mkg...@jagit.co.uk>
> Gesendet: Freitag, 17. Februar 2017 11:00:49
> An: mkgmap-dev@list
rgeObjectAreas.
> I think I should remove it.
>
> Gerd
>
>
>
>
>
>
> Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag
> von Ticker Berkin <rwb-mkg...@jagit.co.uk>
> Gesendet: So
>
> Gerd
>
>
> Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag
> von Ticker Berkin <rwb-mkg...@jagit.co.uk>
> Gesendet: Freitag, 13. Januar 2017 09:54:01
> An: mkgmap-dev@lists.mkgmap.org.uk
> Betreff: Re: [mkgmap-dev] new branch split-s
ize). But 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://www.mkgmap.org
oo.
>
> 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 effects yet. I h
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/options.txt
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
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 "rewrite classes that hold information about map objects, esp.
>
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
ll 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 clipping to a rectangl
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 the pre-test
> to
ings 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
> Gesendet: Donnerstag, 10. N
tPpolygonRelation.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> ;
>
> Ciao,
> Gerd
>
>
> Tic
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
> > Hi
> &g
patch
Ticker
On Sat, 2016-11-19 at 10:46 +, 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 from one of my map
h. I was not yet able to reproduce the problem
> reported by rheinskipper1000. Do you have a test case for me?
>
> Gerd
> Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag
> von Ticker Berkin <rwb-mkg...@jagit.co.uk>
> Gesendet: Mittwoc
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
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
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]
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
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-
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
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
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
or 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, thread was
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 --order-by
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.
>
>
ebWc
> > >
> > >
> > >
> > > Von: svn commit
> > > Gesendet: Freitag, 11. November 2016 17:11
> > > An:
> >
> > > mkgmap-svn@.org
> >
> > > ;
> >
> > > mkgmap-dev@.org
> >
> > >
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
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't reflects what will
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
> zones.
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.
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
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
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:
:49 +0100, Arndt Röhrig wrote:
> Hi,
> Thank you all for the support!
>
> Best regaards
>
> Ticker Berkin <rwb-mkg...@jagit.co.uk> hat am 2. Dezember 2016 um
> 15:22 geschrieben:
>
>
> I'll have a look. I didn't intentionally change extended type
> behavio
:
> 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-shape\dist\mkgmap.
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:
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
s an example.
> And sorry, I should already have coded one for
> clipSinglePathWithSutherlandHodgman().
>
> Gerd
>
>
>
> Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag
> von Ticker Berkin <rwb-mkg...@jag
n branch, not sure if you
> can update one that I've created.
>
> Gerd
>
>
> Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag
> von Ticker Berkin <rwb-mkg...@jagit.co.uk>
> Gesendet: Donnerstag, 12. Jan
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
sion 3742)
+++ src/uk/me/parabola/util/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.me.parabol
1 - 100 of 1100 matches
Mail list logo
