Hi Gerd
Considering no_hp-overflow_alpha.patch:
It seems wrong to change a 24bit coordinate. Utils.toMapUnit() is well defined
to do the
expected rounding with the conversion.
The actual deltas are local to Coord.java and, apart from their use by
getAlternativePositions,
are just used to get b
rea.subtract() and the returned coord is
> converted back but
> get's the other extreme. In the end, only the 24 bit value is written to the
> map, and that
> causes the gap.
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag von
>
the attached patch which
> makes use of the
> coord pool.
> No idea which one has more effects on performance.
>
> Gerd
>
>
>
>
>
> Von: mkgmap-dev im Auftrag von
> Ticker Berkin
>
> Gesendet: Mittwoch,
, 2023-10-05 at 16:37 +0100, Ticker Berkin wrote:
> Hi Gerd
>
> I've changed the way mapUnit and highPrec Coords are calculated slightly so
> that the exact 1/2
> unit boundary values are consistent between negative and positive. This gets
> rid of my couple
> of
> ab
Hi Gerd
My change to toMapUnit should be almost undetectable. Imagining mapUnits [x] as
degrees over the
real range -2.5 .. +2.5, the original implementation resulted in:
-2.5 < [-2] <= -1.5 < [-1] <= -0.5 < [0] < -0.5 <= [1] < +1.5 <= [2] <
+2.5
I've changed it to give:
-2.5 <= [-2] <
Hi Gerd
Sorry - bit hasty in my reply
I need to look at the other places that use DELTA_SHIFT and check their
arithmetic/rounding etc
is consistent with the corrected highPrecCoord and uniform in rounding
behaviour.
Ticker
On Fri, 2023-10-06 at 16:15 +0100, Ticker Berkin wrote:
> Hi G
Hi Gerd
I've looked through all the places I could find that took [highPrec]coord vals,
manipulated them
and then converted back and they all seem safe with my patch.
There might be slight differences where, using Java2DConverter or similar, a
calculated value
converts to a different/adjacent h
Hi Diego
If you use the --gmapi mkgmap option it will make the folder (named with
--family_name option)
and contents, including Info.xml
Ticker
On Tue, 2023-10-10 at 15:15 +, helter skelter wrote:
> Hello guys
> When I create the map for Basecamp, I get a folder under
> ProgramData\Garmin
Hi Gerd
Looking at the code, there shouldn't be any crash from mkgmap if a contour line
doesn't have an
"ele" tag. I assume the Garmin device will just draw the appropriate line
without a label. This
might be common where alternate contours are not given heights.
So, no; I don't think you shoul
Petermann wrote:
> > Hi Ticker,
> >
> > if you don't mind I'd like to postpone this patch until the active branches
> > are merged into
> > trunk.
> >
> > Gerd
> >
> >
> >
> > Vo
rmann wrote:
> > Hi Ticker,
> >
> > please can you provide a unit test for this?
> >
> > Gerd
> >
> > ____
> > Von: mkgmap-dev im Auftrag von
> > Ticker
> > Berkin
> > Gesendet: Donnerstag, 12.
Hi Diego
On the issue of case, your build is probably running without --lower-case, so
everything in the .img file is UPPER. The Garmin device then initcaps stuff in a
way of its own choosing.
Use of --lower-case can cause problems and unknowns with the index system where
there are different case
Sorry - should say ... {tag|subst: ...
Ticker
On Wed, 2023-12-13 at 10:18 +, Ticker Berkin wrote:
> Hi Diego
>
> On the issue of case, your build is probably running without --lower-case, so
> everything in the .img file is UPPER. The Garmin device then initcaps stuff in
>
Hi Karl
You could simply not match it in "polygons" but render the lines that define it.
Alternatively, what I do, is catch it early in "polygons" to render it but with
[... continue] and render it striped/transparent with a high _drawOrder.
[_polygon]
Type=0x16
String=Nature Reserve
Xpm="32 32
Hi
The disadvantage of using extended points is that none are findable.
I've had trouble with 0x2b (Lodgings) points showing or not on different devices
(eTrex HCx & eTrex 30x) and software and some subtype# not being findable on
different devices.
HCx has Lodgings (0x2b) "Find" categories:
0:Ot
Hi Brad
Lines like this follow the type code and, as a comment, describe the standard
Garmin usage, eg:
...
[_polygon]
type=0x02
;GRMN_TYPE: Urban Areas/SMALL_CITY/Small urb...nts/Non NT
String=Suburb
String1=0x01,Résidentiel
...
Ticker
On Mon, 2024-01-29 at 17:43 -0700, brad wrote:
> I was com
derstand: when I use a typ code, and my own typ file,
> when does garmin do something differently than what I expect?
>
>
> On 1/30/24 02:39, Ticker Berkin wrote:
> > Hi Brad
> >
> > Lines like this follow the type code and, as a comment, describe the
> > s
Hi Joao
The default style has logic at the end of the "lines" file to use road numbers
(ref) in various highway-symbol shields and also to use the multiple name
facility to then allow specification of the name and other references for
searching.
If you don't want this then the logic could be adap
Hi Gerd
The unix man entry looks fine
$ man -l ${splitterSvn}/trunk/doc/splitter.1
but I don't know how anyone would be expected to find and use it unless it gets
installed with the other man pages
dist/doc/splitter.txt and .html generated with mwconf from doc/splitter.txt are
attached; I don't
which is of no use.
>
> I've committed r654 for now. Not sure what to do with your version of
> splitter.txt.
>
> Gerd
>
>
>
> ____________
> Von: mkgmap-dev im Auftrag von Ticker
> Berkin
> Gesendet: Freitag, 5. April
hen either.
Ticker
On Fri, 2024-04-05 at 16:08 +0100, Ticker Berkin wrote:
> Hi Gerd
>
> Looking at the svn log it seems that the man page splitter.1 which is in groff
> format can be generated from splitter.1.xml which is in DocBook XML format. I
> can't be bothered to install and
Hi Gerd
I'll need to look carefully at this code again.
ISTR the 46 degrees was to stop arcs getting into the same compact segment when
they shouldn't. My changes stopped a lot of incorrect turn instructions but
maybe there is still scope for the algorithm to look for the same road entered
and ex
e increases a bit,
> > > > but
> > > > I
> > > > think that is better than wrong turn instructions.
> > > >
> > > > Let me know if you cannot reproduce and I'll create a more complete
> > > > description reg. the op
why
and, since the arcHeading_v2.patch in Oct 2020 I haven't found any that are
fixable; I couldn't find a solution where the major road continues at an angle
and the minor side road continues straight on.
Ticker
On Mon, 2024-08-05 at 19:14 +0100, Ticker Berkin wrote:
> Hi Gerd
>
Hi Thorsten
Is the problem still with node https://www.osm.org/node/27550903 and ways
36138336 / 144732811
I've loaded this example and looked at the angles before and after adjustment
with my patch. From the south the way enters the node with heading 161.6 and
leaves with heading -16, giving an
hich angles are
"sharp" and AngleChecker doesn't do anything if there are no sharp angles.
Regards
Ticker
On Thu, 2024-08-08 at 15:11 +0200, Thorsten Kukuk wrote:
>
> Hi,
>
> Am 2024-08-08 14:22, schrieb Ticker Berkin:
> > Hi Thorsten
> >
> > Is the p
which case the continuous way might be lower priority than the joining
way and the algorithm prefers to this.
Regards
Ticker
On Thu, 2024-08-08 at 17:11 +0200, Thorsten Kukuk wrote:
> Am 2024-08-08 16:52, schrieb Ticker Berkin:
> > Hi
> >
> > First of all did you have these va
Hi Thorsten
The algorithm, in choosing which arc headings to adjust to remove sharp turns,
prefers to adjust lower class roads. If class is the same it adjusts lower speed
road. If these are the same, with my change it, it sees if one is reasonably
straight and adjusts the other. As a last resort
ikely same road", then road_speed.
Ticker
On Sat, 2024-08-10 at 16:27 +0100, Ticker Berkin wrote:
> Hi Thorsten
>
> The algorithm, in choosing which arc headings to adjust to remove sharp turns,
> prefers to adjust lower class roads. If class is the same it adjusts lower
> speed
>
; The way starting at the junction to the left is
> https://www.openstreetmap.org/way/144732811 and has
> road_class=2 and road_speed=2 in my style.
>
> Regards,
> Thorsten
>
> Am 2024-08-10 18:38, schrieb Ticker Berkin:
> > Hi Thorsten
> >
> > Let me know if the road_spee
Hi Thorsten and Gerd
I've looked at examples around my area where a higher class way terminates (at a
sharp angle) in the middle of a way or 2 straight ways and, in none that I
found, would it be a problem to adjust the angle of the higher class road.
I've re-done the patch to this effect, also a
Really sorry, previous patch was wrong. Correct one attached
Ticker
Index: src/uk/me/parabola/imgfmt/app/net/AngleChecker.java
===
--- src/uk/me/parabola/imgfmt/app/net/AngleChecker.java (revision 4921)
+++ src/uk/me/parabola/imgfmt/
en Kukuk wrote:
>
> Hi Ticker,
>
> Am 2024-08-12 13:14, schrieb Ticker Berkin:
> > Really sorry, previous patch was wrong. Correct one attached
>
> Sorry, but for https://www.openstreetmap.org/#map=18/49.47851/10.94281
> this has still no effect.
> But I think I f
Hi Thorsten
I can't explain the turn instructions being in the wrong direction for some
ranges of angles. What are you seeing this on - Basecamp / MapSource / Garmin
Device?
At the moment I'm more concerned with why, for your first example, we get
different arcs being adjusted. I've added more di
i Ticker,
>
> Am 2024-08-14 17:48, schrieb Ticker Berkin:
> > Hi Thorsten
> >
> > I can't explain the turn instructions being in the wrong direction for
> > some
> > ranges of angles. What are you seeing this on - Basecamp / MapSource /
> > Garmin
Hi Gerd
Could this just be put into dist/examples as the attached file, with svn comment
something like:
Added AppStream metainfo XML with hardware provide info.
This allow isenkram to propose this package when the relevant hardware is
present.
Author: Petter Reinholdtsen
Ticker
On Mon, 2024-08
Hi Gerd
I'm confused by some logic in imgfmt/app/net/AngleChecker.java and wondered if
you could help.
If not a cycle-map, sharpAnglesCheckMask is set to ACCESS...BIKE = 0x2 (~line
134)
Later (~line 294) when the code is looking at an angle and the arcs either side
it ignores a sharp angle (ie w
e values are
- * changed so that angles appear larger.
- *
+ * changed so that angles appear larger.
+ *
* @author Gerd Petermann
*
* Somehow these penalties are also applied to "shortest" routing,
@@ -55,6 +55,13 @@
*
* Ticker Berkin
*
+ * This code has two other functions:
+ *
ut success so far.
> I think that's good news, but all cases only involved footways or tracks so
> far.
>
> So, I wait for Thorsten to confirm that the patch is an improvement.
>
> Gerd
>
>
>
> ____
> Von: mkgmap-dev
about or a
more major road and the angle wasn't increased, but there are other cases where
it should be, so I've removed this as a special case.
Patch attached
Ticker
On Mon, 2024-08-26 at 17:16 +0100, Ticker Berkin wrote:
> Hi Gerd & Thorsten
>
> I need to test one more sce
Hi Thorsten
Thanks for testing this.
The routable line types are:
0x01 ... 0x13 highways
0x16 highway
0x1a ... 0x1b ferry
on newer garmin devices/Basecamp
0x2c ... 0x2f ?/Climbing path/Via Ferrata/Cable Car
Using these for non-routables can break routing nearby in some Garmi
se to this type of
error.
Regards
Ticker
On Mon, 2024-09-02 at 09:43 +0200, Thomas Morgenstern wrote:
> Hello , I use mkgmap-4921 with patch from Ticker Berkin -Angelchecker-V6.
> With that i get in Scandinavia following error : Internal Error Failed to
> render MultiPolygonRelation 1754
gt; programmer and can not do deeper investigation or find a solution. If you
> interested, I can give you my polygon and the .osm.pbf.
>
> Thomas
>
>
> Am 02.09.2024 um 15:04 schrieb Ticker Berkin:
>
>
> >
> > Hi Thomas
> >
> > I get sim
ht be faulty with intersections of the various components and
partitioning with ShapeSplitter can expose these problems. Does the JOSM
verification detect this.
Otherwise this is beyond me.
Regards
Ticker
On Tue, 2024-09-03 at 17:09 +0100, Ticker Berkin wrote:
> > Hi Thomas
> >
> &g
rmann
> Gesendet: Freitag, 6. September 2024 18:02
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Internal Error Failed to render Multipolygon
>
> Hi Ticker,
>
> Maybe the JOSM test doesn't work correctly. I think e.g. this way
> https://www.osm.org/way/339720813
Hi Gerd
I started to think about this a while ago when I was fixing cities >
65535, and introduced some alternative names for get/getChar and
put/putChar and also added some of the assertions. But then I noticed
that some of the names I used were used for BIT I/O elsewhere, and also
the Display tr
Hi
I think it is important to indicate if a signed or unsigned is being
written so that the range can be asserted:
eg:
public void putU1(int val) {
assert val >= 0 && val <= 255 : val;
buf.put((byte)val);
}
and
public void putS1(int val) {
>
> ________
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Montag, 19. Februar 2018 10:19:56
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] methods to write signed / unsigned integers
>
> Hi
>
> I think
Hi
I noticed that the default style was putting walkways around some piers
because of the line rule:
(man_made=pier | man_made=piste:halfpipe) & area!=yes
{add highway=footway; name '${ref} ${name}' | '${ref}' | '${name}' }
an example is:
WAY: 469580183 (50.73379039764404/-1.2820744514465332) [m
tyle_func()=val {...}
> This works fine
> a=* & style_func()!=val {...}
> or
> a=* & style_func()>val {...}
>
> @Steve: I assume that the problem is in the rule optimizer?
>
> Gerd
>
>
> Von: mkgmap-dev im Auft
e-Garmin
>
> Joris
>
>
>
> -Oorspronkelijk bericht-
> Van: mkgmap-dev Namens
> Ticker Berkin
> Verzonden: zaterdag 24 februari 2018 13:36
> Aan: mkgmap development
> Onderwerp: [mkgmap-dev] line rule not being triggered
>
> Hi
>
> I noticed t
Hi Gerd / Steve
Starting from Steve's patches (getting.patch, msg.patch and img
-write.patch), I've changed mkgmap+test to have/use:
int get1s(), get2s(), get3s(), get4()
ing get1u(), get2u(), get3u(), getNu()
put1s(int), put2s(int), put3s(int), put4(int)
put1u(int), put2u(int), put3u(int)
Hi
I almost always get "Route Calculation Error" on my Garmin when a ferry
crossing is required. GPSMapEdit "Tools > Test Routing Graph" does find
the routes and it shows reasonable properties for the ferries, walkways
and relevant roads.
I'm testing it with a mix of foot and car ferries. In the
Using GPSMapEdit to look at the coordinates of the first point in the
ferry way, the one that worked has the points in the direction of
travel, and the one that didn't has them the other way around (but
neither is marked one-way)
Ticker
On Mon, 2018-03-12 at 15:31 +0000, Ticker Berkin
d Petermann wrote:
> Hi Ticker,
>
> the direction should not matter. What vehicle do you use for routing?
> The one that works has no toll=yes tag. Maybe your style does
> something special with toll=*?
>
> Gerd
>
> ________
> Von: mkg
; try to find a reason.
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Montag, 12. März 2018 18:30:31
> An: mkgmap-dev@lists.mkgmap.org.uk
> Betreff: Re: [mkgmap-dev] Route Calculation Error and Ferrie
Hi
Using Basecamp 4.6.2 and the gmapsupp.img from my Garmin Etrex, after
turning off the relevant "Avoid"s from profiles:
It will generate "Walking" routes using various ferries to the I.O.W:
https://www.openstreetmap.org/way/614416 Sotn.-W Cowes foot
https://www.openstreetmap.org/way/614415 Sot
Hi Andrzej
No - I checked all of this. A couple of ferries wouldn't route to/from
the public highway network because of this (access=destination), but
one didn't have this tagging on its service roads and Basecamp would
route using the ferry as long as the start and end points (on public
roads) we
r pedestrian routing, but for cars
> I've often seen that.
>
> Gerd
>
> ________
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Dienstag, 13. März 2018 15:09:50
> An: mkgmap-dev@lists.mkgmap.org.uk
> Betreff: Re: [mkg
Hi Gerd
I've attached the Display patch - this was a quick hack global edit and
could be improved by using the relevant signed/unsigned get methods
instead of masking... I'm happy to do this - let me know.
Yes to DEM changes. Also the nearby asserts can go now because put2s()
will check the rang
se if (restrbytes == 3) {
> size = reader.get2u() & 0xff; // %%% think
> mistake
>
> I've not used NodConvert for a long time, it might well be behind the
> last findings reg. NOD.
>
> Gerd
>
>
> _
Hi Joris
To see the value of a function in the echotags try something like:
relevant-condition & length() > 0 {}
relevant-condition {echotags 'length'}
the cache value of the length should be in the tags
Regards
Ticker
On Sat, 2018-03-24 at 18:49 +, Joris Bo wrote:
> Hallo
>
> Thank you,
Hi Gerd
I was hoping you'd apply/commit img_io_3.patch (15-mar, from you) and
the display_io_1.patch (15-mar, from me) and then I'll do another
global edit and tidy-up on Display as per the posts on 16-mar.
Regards
Ticker
___
mkgmap-dev mailing list
m
I was being a bit too severe. Zero and negative width/height
subdivisions previously were allowed through without being noticed,
with the negative quietly overflowing looking positive.
The attached patch downgrades the message for zero size to a warning
but flags an error for neg.
Regards
Ticker
Hi
These messages will disappear with the negSubDiv.patch posted today in
"area_size() function to be used in points file" thread.
Regards
Ticker
On Thu, 2018-04-19 at 18:37 +0300, Harri Suomalainen wrote:
> Confirmed, I'm getting a lot of these as well (on 4168, those did not
> appear day or tw
Hi Gerd & Steve
I've done another pass through Display to remove lots of casts and
masking.
This required removed the overloading of
Displayer.setBytes(byte/char/short/int) by having setBytes1/2/4() to
match the existing setBytes3()
DisplayItem.getValue() now returns the same value as fed in wi
Hi
A while ago I noticed that mkgmap doesn't handle the case where the
inner or outer of a multipolygon relation is a multipolygon.
It doesn't handle it in two ways:
1/ During the reading of relations, if the relation references another
relation that hasn't been read yet, it is added to a deferr
t contain other
> relations. Where did you find them?
>
> Gerd
>
> ____
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Dienstag, 24. April 2018 17:42:57
> An: mkgmap development
> Betreff: [mkgmap-dev] Multipolygon rela
Hi Gerd
Reading and checking the initial getting.patch and your fix yesterday,
I've noticed a few lines in the same file that should be changed for
clarity and to make them similar to other logic in the same file.
I also noticed a 3 byte signed offset for fetchLabel that has been
wrong for a long
Hi Gerd
I've been have a look at this as well.
The pre-io-change version of putNu didn't check that the value could be
expressed in the given nBytes, so this error could have existed for a
while
The logic in MDR29 just picks the last record in
private final List index = new ArrayList<>()
Hi Gerd
The asserts in TREFile.setBounds could be removed. This will change the
allowed min value from -8388607 to -8388608. Not sure what this means
though, but probably what happened before
Ticker
On Wed, 2018-04-25 at 16:57 +, Gerd Petermann wrote:
> Hi Felix,
>
> it seems you use a ve
to set max17 looks
> suspicious.
> Can't test right now, I think we just have to change
> this.max17 = r.getMdr17();
> to
> this.max17 = Math.max(this.max17, r.getMdr17());
>
> Do you agree?
> Gerd
>
>
>
> ________
&
Hi Gerd
Does the splitter allow tiles to cross the +-180 line? If so that will
cause a lot of logic problems in calculating widths and min/max
latitudes.
If not, and a tile has to stop with either the LHS at -180 or the RHS
at +180 then things shouldn't be so bad apart from the exact boundary
co
Hi Gerd
I think this patch fixes an as yet undiscovered problem and won't cause
any other problems.
Regards
Ticker
On Wed, 2018-04-25 at 11:27 +0100, Ticker Berkin wrote:
> Hi Gerd
>
> Reading and checking the initial getting.patch and your fix
> yesterday,
> I've n
___
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Montag, 14. Mai 2018 10:54:45
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] r4175 & canary-islands dont work
>
> Hi Gerd
>
> I think this patch fixes an as yet undiscovered problem a
used as flags and so get masked out.
So, I hope it won't cause any additional problems.
Regards
Ticker
On Tue, 2018-04-24 at 11:37 +0100, Ticker Berkin wrote:
> Hi Gerd & Steve
>
> I've done another pass through Display to remove lots of casts and
> mask
Here is display patch based on r537
Ticker
On Mon, 2018-05-14 at 12:18 +, Gerd Petermann wrote:
> Hi Steve, Hi Ticker,
>
> okay, I've removed NodConvert.
>
> @Ticker: If you have a working patch based on r537, please post it.
>
> Gerd
>
>
> Von: mk
ems but I
> think it should be put3u.
> See attached patch.
>
> Gerd
>
> ____
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Montag, 14. Mai 2018 14:48:01
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-d
Hi Gerd
I'd like to check how many places would need to be changed where
longitudes of +180 might be written before changing the low level
assert
I'll do that now
Ticker
On Tue, 2018-05-15 at 05:04 +, Gerd Petermann wrote:
> Hi Steve,
>
> thanks for reporting. I think this problem is cause
Hi Gerd
There are very few places that write 24 bit longitudes
patch attached - what do you think?
Ticker
On Tue, 2018-05-15 at 10:29 +0100, Ticker Berkin wrote:
> Hi Gerd
>
> I'd like to check how many places would need to be changed where
> longitudes of +180 might
Could the extra routing nodes cause a time penalty in the routing
algorithm, in a similar way that 'sharp-angle-fixer' attempts to deal
with?
Ticker
On Sat, 2018-07-07 at 08:01 +, Gerd Petermann wrote:
> Hi Manfred,
>
> If you created the two maps from exactly the same input files and
> with
Search for all the types of POI I've tried work fine, esp local food,
with and without "select category". This is with build from the latest
svn trunk and versions over the previous months. Style is much like
"Default" for POI
Build command:
java -Xmx1540M -ea -jar ../mkgmap.trunk/mkgmap.jar --max
On my device (eTrex Legend HCx) nearby results appear almost instantly.
I don't know if it is of any significance but my style doesn't used
extended types for anything!
Looking at the thread Thorsen mentioned - this I presume:
http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2014q1/020569.html
it
s.
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Donnerstag, 12. Juli 2018 16:21
> An: mkgmap-dev@lists.mkgmap.org.uk
> Betreff: Re: [mkgmap-dev] Error in index
>
> On my device (eTrex Legend HCx) nearby results appea
Hi
Just been having a quick look at this area. My "Find Address" has only
has input for "Region", "City", "Number" & "Street Name". The "Region"
options are the Countries in my map, with "United Kingdom" pre
-selected. It seems to work OK - changing the region to another country
gives cities in th
a Garmin program?
>
> Mkgmap writes the Mdr27 index only for the PC index, not for the
> gmapsupp index.
>
> Gerd
>
> ____
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Montag, 30. Juli 2018 12:40
> An: Development
Hi Gerd
Not a problem as such, but "display" fails to build against this:
[javac] Compiling 76 source files to
/norbert/display/trunk/build/classes
[javac] /norbert/display/trunk/src/test/files/RgnFile.java:273:
error: incompatible types: int cannot be converted to Coord
[javac]
Hi Gerd
A while ago, when I was trying to understand the multi-polygon code,
one of the first things to strike me was that it seems to make things
more complicated that they should be by not keeping the inner and outer
ways parts separate during the initial processing in
MultiPolygonRelation done
Hi
I seem to remember there was a suggestion a while ago (before may 2017)
to reorder the styles/default/polygons to move the include
'inc/*_polygons' up in the file to before "# building tag should be
last". I did this and had no problem with Lake Garda when I generated
italy-latest in July this
efault
> style in next release, since we may have other lakes or bays that are
> labelled as tourist=yes - which may not be wrong for scenic touristic
> areas.
>
> Thanks!
> Enrico
>
> On Tue, Sep 11, 2018 at 7:20 PM Ticker Berkin > wrote:
> > Hi
> >
> &g
Hi Gerd
This patch moves the contents of inc/ landuse_points, landuse_polygons,
water_lines, water_points and water_polygons inline and deletes rules
if they have already occurred in the main file. IE there shouldn't be
any change in meaning.
After applying, you need to svn delete the above inc/
ion mkgmap-r4244 was committed by gerd on Mon, 24 Sep 2018
> > >
> > > Reduce number of includes in default style
> > >
> > > The removed includes were only included in one file and some
> > > rules were repeated.
> > > unIncDefault.patch
Hi all
Some comments on this and other requests/ideas relating to TYP file.
Beware of moving the test for building=* up in the file - there might
be other, more significant, tags that won't be triggered
My Garmin device doesn't show polygons with type > 0x5f, lines > 0x3d, points >
0x72. I have
00:16 -0600, Gerd Petermann wrote:
> Hi Ticker,
>
> Ticker Berkin wrote
> > Does anyone know if it would be possible to change mkgmap to allow
> > this?
>
> Not sure if this is what you want, did you try default_name?
> See e.g.
> amenity=emergency_phone [0x2f12 re
I've just got a new Etrex 30x, updated with the latest firmware, and
most of the searching is very slow compared with my almost 10 year old
Etrex Legend.
Using mkgmap generated map of the British Isles:
On the Legend, earching for city gives a narrowed list as fast as I can
type in each character
/ this is unadulterated size, +ve if clockwise
> > I guess that +ve means positive? This is hard to understand for a
> > non-native speaker who grew up before SMS and Twitter and just
> > learned to use smileys ;-)
> >
> > Gerd
> >
> >
Hi
I'm having problems with the TYP file appearing corrupt. A simple file
was working as expected, but adding a bit more caused very strange
display properties in unrelated items on the Garmin device - eg, an
area showed as a pattern never seen before, and, when selected, claimed
to be waypoint.
Hi
I've just found the note that says non-line pixmaps must be 32x32 so
that is probably my problem.
Testing it now.
Ticker
On Fri, 2018-11-09 at 13:06 +0000, Ticker Berkin wrote:
> Hi
>
> I'm having problems with the TYP file appearing corrupt. A simple
> file
>
Thanks Steve
I've applied the patch to my system and it behaves as expected.
Ticker
On Fri, 2018-11-09 at 15:34 +, Steve Ratcliffe wrote:
> Hi Ticker
>
> > I'm having problems with the TYP file appearing corrupt. A simple
> > file
> > was working as expected, but adding a bit more caused ve
Hi
I'd like to make quite a few changes and improvements to the default
style.
Some of these should be non-contentious:
The first change I propose is to make the layout consistent and clearer
and I've attached a patch to do this for the points/lines/polygons
files. The only change here is white-
401 - 500 of 1134 matches
Mail list logo
