Hi Gerd
Just doing more experimenting with mkgmap-NET-no-NOD-r4304 and options:
--no-route --net
I get lots and lots of messages like:
WARN: uk.me.parabola.mkgmap.reader.osm.ElementSaver 74210002.osm.pbf:
ignoring unspecified/unsupported restriction
http://www.openstreetmap.org/relation/39317
ps://www.openstreetmap.org/way/153273366 is empty.
> Do you think that mkgmap should start guessing what the role of the
> way is? In this case that would be possible, but I'd still prefer
> that someone fixes the data in OSM.
>
> Gerd
>
> ______
Hi Gerd
I noticed this problem in April and there was a fix to it in the patch
that simplified/clarified point type/subtype and city range handling:
http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2019q2/029623.html
The posting didn't elicit any responses, but I think the changes
worthwhile. If you w
Hi Gerd
Here is the patch based on the current trunk
Ticker
On Tue, 2019-04-23 at 11:51 +0100, Ticker Berkin wrote:
> Hi
>
> I think the mkgmap internal handling of types/subtypes of points is
> obscure.
>
> In the points style file, the type code is always full, ie type
ycle:conditional=* & bicycle:conditional ~
> '!(sunset|sunrise|destination)' { name
> 'bicycle=${bicycle:conditional}' } [0x1108 resolution 24]
> vehicle:conditional=* & vehicle:conditional ~
> '!(sunset|sunrise|destination)' { name
> 'vehicle=${vehicle:co
ched patch which is work in progress. I did not yet make up
> my mind regarding lambdas. They are nice to simplify code but
> sometimes it is much harder to debug them in Eclipse.
>
> ________
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Ges
Hi Gerd
Testing mkgmap-NET-no-NOD-r4304 with 2 tile local area with option
--x-check-routing-island-len=700
Some build statistics:
SEVE: uk.me.parabola.imgfmt.app.net.RoadNetwork 74210002.osm.pbf:
check for routing islands found 293 islands
SEVE: uk.me.parabola.imgfmt.app.net.RoadNetwork 74210
test for routing islands performed in < 50
> ms. So, there seems to be a special case.
> Also, I did not see that big effect on img siz.
> Please can you test with default style for comparison?
>
> Gerd
>
>
> Von: mkgmap
options and the area for 74210001.
> Maybe try with commented the log statements (except the one for the
> timing )
>
> Gerd
>
> ____
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Dienstag, 22. Oktober 2019 18:33
> An:
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Dienstag, 22. Oktober 2019 19:24
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Please test branch NET-no-NOD
>
> Hi Gerd
>
> split.list
tyledConverter should also calculate the island length given by --x
> -check-routing-island-len before removing it.
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Mittwoch, 23. Oktober 2019 12:38
t of command
> java -version
>
> Mine is:
> e:\ld>java -version
> java version "1.8.0_221"
> Java(TM) SE Runtime Environment (build 1.8.0_221-b11)
> Java HotSpot(TM) 64-Bit Server VM (build 25.221-b11, mixed mode)
>
> Gerd
>
> _____
Hi
It looks like this proposed feature was rejected by the OSM community:
https://wiki.openstreetmap.org/wiki/Proposed_features/through_route
and, as there are few examples of its use, I suggest disabling or
removing the code.
I couldn't see from this web page if there was a recommended way of
Hi Gerd
I get this with r4338:
java.lang.IndexOutOfBoundsException: Index: 0
at java.util.Collections$EmptyList.get(Collections.java:4454)
at
uk.me.parabola.imgfmt.app.net.NETFile.createSortKeysyNameAndCity(NETFil
e.java:166)
at
uk.me.parabola.imgfmt.app.net.NETFile.deDupR
___
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Samstag, 2. November 2019 19:30
> An: mkgmap development
> Betreff: Re: [mkgmap-dev] [mkgmap-svn] Commit r4338: merge from trunk
> r4337
>
> Hi Gerd
>
> I get this with r4338:
>
> j
Hi
I think the default should be either:
Don't check for routing islands
or:
Check for and remove islands of any length
but I don't feel that strongly about this aspect.
In the documentation, it should mention the effect of a road meeting a
tile boundary or boundary nodes added at admin bound
ike you say).
> I found no older versions of mkgmap where this would have worked
> different, so it seems useless to me because normally I'd want to be
> able to find the bus station under transport services.
>
> Why do you use 0x1101, 0x1102, or 0x1108 for POI?
>
> Gerd
&g
for all routable lines in my style
> -file. The unconnected_type is now obsolete if you just used to
> disable routing by setting an unroutable type - correct?
>
> Have you tested that the global option is run after
> semi_connected_type and unconnected_type? Because first the style
>
yes, sorry. my email spell checker is set to american and I wasn't
thinking.
Ticker
On Tue, 2019-11-05 at 11:40 +0100, Colin Smale wrote:
> On 2019-11-05 11:12, Ticker Berkin wrote:
> > Also fix "metres" to "meters"
> >
> Metres is t
__
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Montag, 4. November 2019 18:12
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] type/subtype of points and cities
>
> Hi Gerd
>
> To stay compatible with "Openfietsmap full"
ze to either 2 or 3, so maybe
> perform the test once in printHeader() using the logger instead of
> System.out.printf()?
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Dienstag, 5. November 2019 12:44
&
rned that Mapsource doesn't like the map produced with
> java -jar mkgmap.jar --index --gmapi test-map:all-elements
> It crashes when you search for all POI and also when you search for
> cities (both without giving a name)
>
> Gerd
>
> ___
>
> Von: mkgmap-dev im Auftrag
> von Gerd Petermann
> Gesendet: Donnerstag, 7. November 2019 13:18
> An: Ticker Berkin; mkgmap development
> Betreff: Re: [mkgmap-dev] type/subtype of points and cities
>
> Hi Ticker,
&g
019-11-07 at 13:15 +, Ticker Berkin wrote:
> Hi Gerd
>
> Yes, I'll change allElements to not try subtypes for isCityType, and,
> elsewhere, assert that indPoints don't have a subtype.
>
> My Etrex only shows points in the range you mention in the results
> fo
ndentation
Ticker
On Thu, 2019-11-07 at 11:56 +0000, Ticker Berkin wrote:
> Hi Gerd
>
> MdrDisplay/cityPtrSize:
>
> I didn't change any significant behaviour. Because it seemed
> inconsistent, I put in a diagnostic. I also made the switch stmt in
> printSec11_city lik
Hi Gerd
It would be good if this idea was resurrected - initially just
releasing the file, as you last had it, somewhere under
trunk/resources. Then suggestions can be incorporated and mention made
of it elsewhere in the documentation.
Ticker
On Thu, 2019-02-21 at 10:50 +, Ticker Berkin
Hi Gerd
I've tweaked the file a bit and put a hint to it in the README in the
root directory of the distribution; this file is very out-of-date but I
didn't want to start re-writing it.
Attached is the updated patch and resources/sample.cfg (which I
couldn't work out how to get into the patch bec
th the file.
> I think the README is not distributed, so you have to change
> build.xml as well.
>
> If you use svn patch with my patch the file is "automagically" svn
> -aded
>
> Gerd
>
> ________
> Von: mkgmap-dev im Auftra
like the changes.
>
> Gerd
>
>
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Montag, 15. April 2019 17:49
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Building map with Hebrew character
Hi Gerd
I'm getting routing problems with Basecamp when using routing island
removal. Building with:
java -jar ../mkgmap.trunk/mkgmap.jar -c ticker.cfg --check-routing
-island-len=700 --family-name=trRIL700 -c template.args ticker.txt
a high proportion of routes fail, ie it just generates a stra
Hi Gerd
Thanks for investigating this. As the eTrex routing seems to work
(maybe it is more similar to Mapsource than Basecamp) I'll persist with
island removal.
Looking at display:NetCheck errors, it looks like the RoadDef.netFlags
bit:
RoadDef: public static final int NET_FLAG_ADDRINFO = 0x10
___
> Von: mkgmap-dev im Auftrag
> von Gerd Petermann
> Gesendet: Donnerstag, 21. November 2019 19:52
> An: Ticker Berkin; Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Basecamp and NET/NOD changes
>
> Hi Ticker,
>
> the attached patch for mkgmap makes
.
>
> Gerd
>
>
>
> Von: mkgmap-dev im Auftrag
> von Gerd Petermann
> Gesendet: Freitag, 22. November 2019 12:57
> An: Ticker Berkin; Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Basecamp and NET/NOD changes
>
might be a new style file containing something like
>
> # routing island replacement types
> 0x01: 0x10800
> 0x02: 0x10801
> 0x03: 0x10802
>
> 0x07: none
> ...
>
> Gerd
>
> ________
> Von: mkgmap-dev im Auftrag
> von Ger
Hi Gerd
I've trying various things, like changing the TYP, removing road
-speed/class, ... to try and pin down this problem and generally, the
behaviour got worse.
I experimented a bit with your cut-down area: ticker-part-mod.zip but
had problems. Way -1477104 confused me for a while. So I went b
RGN
> file and uses the pointers to NET in it.
>
> Gerd
>
> ________
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Dienstag, 26. November 2019 17:31
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Basecamp and NET/NOD changes
>
>
Hi
With option --generate-sea=multipolygon,... the rule in polygons:
> natural=sea {add mkgmap:skipSizeFilter=true; set mkgmap:drawLevel=2}
[0x32 resolution 10]
does the work for the sea and the rule in lines:
> natural=coastline [0x15 resolution 12]
draws the coastlines, both working from the s
Hi Gerd
I think it would be good if the files from branches/default
-typ/resources/typ-files were put into trunk and, in build.xml, after:
this is added:
Ticker
_
t; I've learned that polygon type 0x3d (natural=bay) in mapnik typ is
> wrong. It renders as a gray area and may hide the sea below.
> I am not sure what the correction is. If possible I would use
> "transparent" without any colour, else the same as 0x32.
>
> Gerd
>
&g
7;ve learned that polygon type 0x3d (natural=bay) in mapnik typ is
> > wrong. It renders as a gray area and may hide the sea below.
> > I am not sure what the correction is. If possible I would use
> > "transparent" without any colour, else the same as 0x32.
> >
> &
Hi
Sorry - seems that the name went from mkgmap.txt
Ticker
On Mon, 2019-12-09 at 15:13 +, Ticker Berkin wrote:
> Hi
>
> My understanding was that mkgmap.txt rather than mapnik.txt was going
> to be one of the typ-files examples
>
> Ticker
>
> On Mon, 2019-12-09
Hi Joris & Gerd
Great to see the typ-files now in trunk and all the work in updating
mapnik.txt to the current default style. Next week I plan to go through
"20191209 mapnik update.pdf" and comment on it and possible changes to
the default style.
Some other questions however:
How do you see mapn
Hi Gerd
This looks fine, but shouldn't the option change be to doc/options.txt
rather than resources/help/options/en/options?
Ticker
On Sat, 2019-12-14 at 11:04 +, Gerd Petermann wrote:
> Hi all,
>
> I plan to document new option --is-in-landuse like this:
> --is-in-landuse=value[,value...
Hi
I have suggestions for changes to the English. Patch attached but the
relevant lines are:
# english
# Not good to have prefixes; in UK they are considered as the first
part of the street name.
#prefix1:en = "East ", "North ", "South ", "West "
# Having suffixes makes Find>Address less easy to
Hi all
As suggested elsewhere, bays should be rendered as transparent and only
generated if named. I use this method for other areas and find it very
useful.
I don't understand what is being suggested by the references to POI in
this context; They are findable as Geographic > Water Features > Ba
Hi
The idea of the transparent polygon is to give a name to an area
without disrupting the rendering of other features in the same area.
The method of seeing this name is device dependent, but, on some,
clicking on the area gives a list of the names of all polygons the
cursor is within.
Using a l
Hi
What needs to be clarified is if the way, possibly closed, has to be
fully within the specified area, or just partially.
Maybe this can be represented as the value of the the created
mkgmap:{areaTag}:{areaValue} tag.
Ticker
On Tue, 2019-12-17 at 11:15 +, Gerd Petermann wrote:
> Hi Nick,
Hi Gerd
I was thinking it would be slow to do the full test and I've seen your
summary of what you've implemented and have no problem with it.
The meaning with either being multiPolygons would be almost impossible
to define, but otherwise I'd define it as such:
Point: if within or on edge then I
Hi David
With option --add-pois-to-area, for all polygons a point is determined
wich is then fed through the style 'points' rules with the additional
tag mkgmap:area2poi=true. It is then up to the 'points' rules to decide
what to do. The determination of the location of the points is
described in
Hi Randolph
This topic should probably become a new thread.
You shouldn't confuse the encoding of the java source text (rules
determined by the java language) with how a java program reads a text
file into its internal character format (however the programmers want
to do it, but the java library
Hi
A couple of problems with typ-files and unicode.
With 'Codepage=65001' the final contents of the labels in mapnik.typ
that is included with the composite map is unicode, but if the map is
codepage 1252, the unicode characters with the top bit set are simply
displayed as if in 1252.
Removing t
n a way that only those lines which contain non-matching characters
> are ignored?
>
> Gerd
>
>
> ________
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Mittwoch, 18. Dezember 2019 19:46
> An: mkgmap development
>
Hi
Given the complexity and cpu cost of calculating this, the various
questions, hence answers possible and it has to be done for all
elements if the --is-in option is given what about making it a function
instead.
This means that it only needs to be computed for elements where the
answer matter
Hi David
If I understand you correctly, you don't want duplication of an element
as both a polygon and a POI, and, for all elements except 'bay', you
want the polygon if define as such by OSM, but not the POI as well, but
for 'bay', you want a POI only, regardless of it maybe being defined in
OSM
Hi Gerd
This is looking more and more complicated with:
1/ High cost of total accuracy
2/ Multi-polygons haven't been processed at the time the hook attempts
to set the tag?
3/ holes due to multi-polygons
4/ lines crossing polygon boundaries where different attribute are
required on either side
5/
the moment, the 'CodePage=' command in the typ-file is, under some
circumstances, used to determine the encoding of the typ-file itself
and I've left this alone for compatibility with existing useage.
Sometime in January I'll provide a better method for this
Ticker
On Wed, 2
Hi Gerd
Do you want me to do anything with this at the moment?
I could add default methods and change the irrelevant implementations
back to the same as trunk, tidy up... or whatever.
I've checked out the branch loaded, but I doubt if I can update it so
I'd have to send you patches.
In the is-in
Hi Jan
--is-in-landuse only existed in revision 4397 (15th - 18th December),
when it replaced and generalised --residential-hook, which was then
restored.
The new style function will be able to perform the functionality of
both of the above and more and should eventually replace them.
The functi
Hi all
In a recent svn commit message, Gerd wrote:
> check both lines and polygons with the same method
> As expected performance is poor when compared to ResidentialHook
If some users were happy with the approximations used by the
--residential-hook implementation, I see no reason why the same
Hi Jan
OK, but Outside needs to be expressed in the inverse, ie
e) any-in-or-on > 3/ 4/ 5/ 6/
and then tested as ... is_in(tag,val,any-in-or-on)=false ...
because the logic will look for all correctly tagged polygons nearby
and then check each in turn to see if it matches the accuracy
require
Hi Gerd
I'll do patch for the function parameters shortly.
Are you trying to trying to check if a way/polygon is in all nearby
polygons simultaneously, or just checking one-by-one until you get
'true'?
If one-by-one, the moment any line crosses then you can stop, with
IN/ON/OUT all being true (u
tch with my current work-in-progress version, lots of
> duplicated code.
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Mittwoch, 8. Januar 2020 12:12
> An: mkgmap-dev@lists.mkgmap.org.uk
> Betreff:
up.
> Probably a first working version tomorrow...
>
> Gerd
>
> ________
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Mittwoch, 8. Januar 2020 14:37
> An: mkgmap development
> Betreff: Re: [mkgmap-dev] Allow blanks in function parameters
>
>
Hi Gerd
I think the logic still needs to know if it is handling a closed way as
a polygon rule or as a line rule.
Firstly to be able to correctly handle the case where the rule.way runs
around a hole in the target.polygon - all of the rule.line is in the
target, but only part of the rule.polygon
example file.
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Freitag, 10. Januar 2020 09:59
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Branch is_in ready for a first test
>
> Hi Gerd
>
> I think the logic still need
and are taken notice of.
Previously, just the UTF-8 BOM was detected.
c/ Typ files can, and should from now on, be written in utf-8
d/ labels for languages not supported in the --code-page of the output
img just generate a warning in mkgmap.log.x
Ticker
On Sat, 2019-12-21 at 16:11 +, Ticker Be
Hi Gerd
This looks to be much better than my solution (FeatureKind vs.
isLineRule)
Ticker
On Sun, 2020-01-12 at 16:28 +, svn commit wrote:
> Version mkgmap-r4417 was committed by gerd on Sun, 12 Jan 2020
> BRANCH: is-in
> Improve IsInFunction:
> partly revert 4412: We need the information ab
Reader br is not
> closed. Is that intended?
>
> I see that we have a mix of "utf-8" and "UTF-8" in the mkgmap
> sources. I think it would be good to use StandardCharsets.UTF_8 where
> possible
> and unify the rest.
>
> Gerd
>
> _______
File(precompSeaDir); // don't close here!
> when a file is intentionally kept open.
>
> Gerd
>
> ________
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Dienstag, 14. Januar 2020 10:43
> An: Development list for mkg
Hi
My earlier postings were to get an idea of what was wanted regarding
combinations of IN/ON/OUT for 'lines' and also what was reasonable to
implement.
I didn't like some of the method keywords that I had suggested either.
The advantages of the keyword, even if ugly/unwieldy, to say what is
wan
Hi Gerd
I've just noticed that a change to a function profile stopped a test
from compiling, so here is a patch for that
Ticker
On Tue, 2020-01-14 at 09:43 +0000, Ticker Berkin wrote:
> Hi Gerd
>
> Here is updated patch that closes the file, although I find many
> files
>
; CharsetProbe (as the unpatched version does)?
>
> Gerd
>
>
>
> Von: Ticker Berkin
> Gesendet: Freitag, 17. Januar 2020 11:54
> An: Gerd Petermann
> Betreff: Re: AW: AW: [mkgmap-dev] TYP files and character encoding
>
> Hi Gerd
>
> I have another
> > ________
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Dienstag, 14. Januar 2020 10:43
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] TYP files and character encoding
> > Hi Gerd
> > Here is updated p
23, please check if my svn
> log message.
>
> Gerd
>
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Freitag, 17. Januar 2020 13:43
> An: mkgmap development
> Betreff: Re: [mkgmap-dev] TYP fi
cursive call?
>
> - You sometimes replaced FileReader, but not in
> CombinedStyleFileLoader. Why not?
>
> We have a few places where we read files which use "#" for comment
> lines. Would it help to create a class for that?
>
> I made a few minor mods, see att
Hi
I have this in my style:
railway=abandoned & highway!=* &
((bicycle=* & bicycle!=no & bicycle!=proposed) |
(foot=* & foot!=no & foot!=proposed))
{set highway=path}
highway=path might be converted by later rules to bridleway, footway or
cycleway
Ticker
On Sat, 2020-01-18 at 18:51 +0
Hi Mike
My utf-8 patch, topic "StandardCharsets and try (with-resources)"
changes the charset used to read mkgmap.jar:help/{lang}/{topic} ie
includes 'options' from the default charset to UTF-8.
What is your default charset?
The characters in --mdr7-excl are utf-8. I didn't find the hyphens.
Ti
.
Ticker
On Fri, 2020-01-17 at 17:04 +, Ticker Berkin wrote:
> Hi Gerd
>
> The line.trim() deletion wasn't intended - I'll put it back.
>
> I think it best to change sortForCode IOException to throw
> ExitException. Maybe they meant to return some default "Sort&
Hi all
Patch attached that makes the following changes to mapnik.txt. This is
held in resources/typ-files and distributed in examples/typ-files.
- Add UTF-8 BOM at the start of the file, so that many text editors and
mkgmap will recognise the encoding.
- Add following line near start of file, fo
idea of a default language using English. What
> happens when the device is set to e.g. Turkish? Doesn't Garmin
> provide a good default string for "Lake" in Turkish?
>
> Gerd
>
> ________
> Von: mkgmap-dev im Auftrag
> von
Hi
Gerd rule should be OK with the addition clause of & highway!=*, but is
there any reason not to have what I suggested.
Ticker
On Tue, 2020-01-21 at 11:36 +0100, Bernhard Hiller wrote:
> Hi Gerd,
> of course, {deletealltags} is a different action: it removes the way
> completely. "{add access=
eeded. I forgot that we
> disabled the mop up rule for highway=*
>
> Gerd
>
> ____
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Dienstag, 21. Januar 2020 12:03
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] change handling of
hing like "use
> build-in label" in the TYP file.
> If that is not the case the patch is an improvement.
>
> Gerd
>
>
> ____
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Dienstag, 21. Januar 2020 11:43
&g
intree,Essex","Chelmsford,Essex", and "Colchester,
> Essex". Each of them points to just one of the expected roads.
>
> Results look much better when I specify a city name.
> Result also looks very different without the --split-name-option.
> I have t
Hi
I have always used the default for this, including the skipSizeFilter
bit for sea as in the default style and had never noticed a problem.
I'm now about to experiment with --min-size-polygon=4.
The value of this option is in Garmin map units, regardless of the
resolution of the sub-map. Assum
) < minSize
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Mittwoch, 29. Januar 2020 12:09
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Squaring off of land outlines
>
> Hi
>
> I have always used the
Hi
Having just generated full britain-and-ireland with current trunk
(r4432), I'm also now seeing some tiles (5 out of 101) with sea/land
flipped when using option:
--generate-sea="multipolygon,extend-sea-sectors,close-gaps=350"
but when I process some of the same tiles with r4295 they are OK.
Hi Gerd
I'm away for a few days. I'll be back on Wednesday and try it then.
Ticker
On Fri, 2020-01-31 at 16:15 +, Gerd Petermann wrote:
> Hi Ticker,
>
> please try this command with openjdk 11 or 13 64Bit:
> java -Xms4G -Xmx10G -jar mkgmap.jar f:\osm\dummy.osm f:\osm\dummy.osm
> f:\osm\dumm
Hi all
I'm still of the opinion that it is better to specify a 'method'
parameter rather than return 3 flags for the following reasons:
- for polygons, it is only meaningful to need to know if ANY or ALL of
the rule polygon is in the target.
- for lines, it was thought better for the 'ALL' case
Hi all
I've also just checked this.
With a typ-file that ensures all lines in range 0x01..0x3f have a
representation, Basecamp shows nothing for:
0x17
0x2c
0x30-3f
whereas my eTrex devices show them all.
I can re-assign barrier to 0x2d, and I'd planned to use 0x2c for
"Course of old Railway", b
alo problem
> and returns true for P1 and P2 and false for P3.
>
> The current code treats polygons like lines but case L3 may return
> different results as the code tries to find out if the tested polygon
> is inside a hole.
>
> Gerd
>
> __
Hi
A possibility would be to use Way.fullArea as the basis for the
filtering. This is calculated early in the OSM reading process and,
assuming the splitter keeps all points of a polygon that crosses a tile
boundary, it should have the same value for all the bits in all the
tiles. It is copied to
Hi Gerd
I don't have a 64bit environment or that much memory. In my normal
environment, I get:
$ java -Xms1500M -Xmx1540M -jar ../mkgmap.trunk/mkgmap.jar \
dummy.osm dummy.osm dummy.osm
Time started: Wed Feb 05 12:56:28 GMT 2020
Setting max-jobs to 4
Number of MapFailedExceptions: 0
Number of E
p://gis.19327.n8.nabble.com/file/t318326/mem.patch> ;
>
> Gerd
>
>
> Ticker Berkin wrote
> > Hi Gerd
> >
> > I don't have a 64bit environment or that much memory. In my normal
> > environment, I get:
> >
> > $ java -Xms1500M -Xmx1540M -jar ../m
Hi Gerd
I've re-implemented the POINT test within IsInFunction, using the
stopping methods etc, which are now coded, but only relevant for this
context at the moment. This implementation has other advantage in that
the method can control the onBoundary condition. Also the logic in
calcInsideness c
> I am not sure but I think splitting at tile borders did not yet
> happen with the polygons, only the preparation is done by adding
> nodes at the tile border.
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Ge
x27;) returns true if the point is
> on the boundary, not in or out.
> With line and polygon rules we merge overlapping polygons before we
> test, so I tried to do something similar with points.
>
> Gerd
>
> ________
> Von: mkgmap-dev im Auft
e test.
>
> Reg. performance it probably doesn't matter much, these cases are
> rare and the point-in-polygon test is rather fast compared to the
> line-in-polygon test.
>
> Gerd
>
>
> ________
> Von: mkgmap-dev im Auftrag
>
:
> Hi Ticker,
>
> "but this isn't necessary for the IN/IN_OR_ON"
> Why not for IN?
>
> Gerd
>
> ____
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Dienstag, 11. Februar 2020 11:07
> An: Dev
Hi
I've started some initial documentation for this that will go into the
Style Manual.
The attached patch lists the options, but you might find it a bit
unreadable.
With the next auto-build after this is applied, the updated manual
appear in the branches download zip. @gerd: is this how it happ
601 - 700 of 1134 matches
Mail list logo
