Re: [mkgmap-dev] More method options for is_in function

[Ticker Berkin]

Hi Arndt

Are you including inc/access from points?

Ticker

On Tue, 2020-02-11 at 13:54 +0100, Arndt Röhrig wrote:
> Hi Ticker,
> 
> i get this:
> 
> 13:40:20,54 - mkgmap .\tools\mkgmap-is-in-r4443 Speiche_Fabrik 
> Error in style: Error: (inc/access:73): Error: Third parameter 'all'
> of function is_in is not supported
> 
> Reason is, the is_in command is in the access-file :)
> 
> Thank you
> 
> Arndt
> 
> 
> 
> > Ticker Berkin < rwb-mkg...@jagit.co.uk> hat am 11. Februar 2020 um
> > 13:02 geschrieben:
> > 
> > 
> > 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 happens?
> > 
> > But the simple answer to your question is, for a rule in "lines" or
> > "polygons", what you have written will still work.
> > 
> > Ticker
> > 
> > On Tue, 2020-02-11 at 12:32 +0100, Arndt Röhrig wrote:
> > > Hi Gerd,
> > > 
> > > is_in(landuse,residential,all)=true
> > > 
> > > how do you write that now?
> > > 
> > > Greets
> > > Arndt
> > > 
> > > > Gerd Petermann < gpetermann_muenc...@hotmail.com> hat am 10.
> > > > Februar 2020 um 14:14 geschrieben:
> > > > 
> > > > 
> > > > Hi all,
> > > > 
> > > > see 
> > > > http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev
> > > > =4442
> > > > 
> > > > @Ticker:
> > > > I assume you are working on an alternative implementation of
> > > > the
> > > > methods in IsInUtil?
> > > > If not I'd like to remove all the code duplication introduced
> > > > with
> > > > the last patch.
> > > > 
> > > > Gerd
> > > > ___
> > > > mkgmap-dev mailing list
> > > > mkgmap-dev@lists.mkgmap.org.uk
> > > > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> > > ___
> > > mkgmap-dev mailing list
> > > mkgmap-dev@lists.mkgmap.org.uk
> > > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev_
> > > __
> > mkgmap-dev mailing list
> > mkgmap-dev@lists.mkgmap.org.uk
> > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Work on is_in branch

[Ticker Berkin]

Hi Gerd

To take advantage of efficiency gains based on knowing what is being
asked for, ie:

- do the polygons need to be merged or can we do one-by-one.
- can we answer correctly even of !W.isComplete().
- can we stop early, eg ANY as soon as part is IN, ALL as soon as part
is OUT, etc

the top layers of code need to be with the method and its associated
knowledge. I don't see any point in simply moving this into IsInUtil.

I was going to take calcInsideness next and divide it into some library
bits remaining in IsInUtil, and logic equivalent to the rest in
IsInFunction.

If you consider this is not the way to proceed, then I'd still like
patch applied anyway, firstly because it contains other changes
unrelated to this, secondly so that the code exists in SVN. I'll then
immediately do another patch that removes the canStop logic etc and the
POINT code that migrated here and restore it to just testing the
composite flags.

Ticker

On Tue, 2020-02-11 at 14:11 +, Gerd Petermann wrote:
> Hi all,
> 
> sorry, something is broken in the mail system. 
> The latest posts don't appear on nabble (1) and my answers to
> existing threads are rejected. 
> 
> @Ticker: I'd prefer to do the merge and I think it should be done in
> IsInUtil. Your patch is_in-function_v7.patch goes in the opposite
> direction.
> Not sure what you plan to do now?
> 
> Gerd
> 
> (1) http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Work on is_in branch

[Ticker Berkin]

Hi Gerd

I assume you mean towards moving some logic from IsInUtil to
IsInFunction.

Ticker

On Tue, 2020-02-11 at 15:41 +, Gerd Petermann wrote:
> Hi Ticker,
> 
> okay, let's see where this goes...
> 
> Gerd
> 
> 
> Von: mkgmap-dev  im Auftrag
> von Ticker Berkin 
> Gesendet: Dienstag, 11. Februar 2020 16:36
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Work on is_in branch
> 
> Hi Gerd
> 
> To take advantage of efficiency gains based on knowing what is being
> asked for, ie:
> 
> - do the polygons need to be merged or can we do one-by-one.
> - can we answer correctly even of !W.isComplete().
> - can we stop early, eg ANY as soon as part is IN, ALL as soon as
> part
> is OUT, etc
> 
> the top layers of code need to be with the method and its associated
> knowledge. I don't see any point in simply moving this into IsInUtil.
> 
> I was going to take calcInsideness next and divide it into some
> library
> bits remaining in IsInUtil, and logic equivalent to the rest in
> IsInFunction.
> 
> If you consider this is not the way to proceed, then I'd still like
> patch applied anyway, firstly because it contains other changes
> unrelated to this, secondly so that the code exists in SVN. I'll then
> immediately do another patch that removes the canStop logic etc and
> the
> POINT code that migrated here and restore it to just testing the
> composite flags.
> 
> Ticker
> 
> On Tue, 2020-02-11 at 14:11 +, Gerd Petermann wrote:
> > Hi all,
> > 
> > sorry, something is broken in the mail system.
> > The latest posts don't appear on nabble (1) and my answers to
> > existing threads are rejected.
> > 
> > @Ticker: I'd prefer to do the merge and I think it should be done
> > in
> > IsInUtil. Your patch is_in-function_v7.patch goes in the opposite
> > direction.
> > Not sure what you plan to do now?
> > 
> > Gerd
> > 
> > (1) http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html
> > ___
> > mkgmap-dev mailing list
> > mkgmap-dev@lists.mkgmap.org.uk
> > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Work on is_in branch

[Ticker Berkin]

Hi Gerd

Here it is - changes are:

- Some restructuring with early stopping where possible.

- Merging polygons for POINT IN/ON test so a point on shared boundary
becomes IN rather than ON.

- Not merging polygons when no need.

- Make the function cacheable, so that there is negligible cost to the
second call:
highway=path & is_in(landuse, residential, all)=true [0xAA]
highway=path & is_in(landuse, residential, all)=false [0xBB]

- Improved the layout of documentation in the Style Manual.

- Fixed quite a few problems.

I've left quite a lot of debug in for the moment, I think there will
still be work to do.

It gives correct answers to 'point-on.osm'. I haven't worked through is
-in-hook-sample-v3.osm yet because I wanted to get this revision out to
replace faults in the previous versions.

Ticker
 
On Tue, 2020-02-11 at 15:49 +, Gerd Petermann wrote:
> Hi Ticker,
> 
> whatever you plan to do. I moved the code to the lib because it is easier to 
> write a unit test.
> I would not invest much time to avoid a few tests which only happen in very 
> rare cases. Makes testing more complicated and code less readable.
> 
> Gerd
Index: doc/styles/rules.txt
===
--- doc/styles/rules.txt	(revision 4445)
+++ doc/styles/rules.txt	(working copy)
@@ -285,19 +285,22 @@
 |is_in(tag,value,method)   | x | x  |  |
 +true+ if the element is in polygon(s) having the specified +tag+=+value+ according to the +method+, +false+ otherwise.
 The methods available depend on the Style section:
-"points":
+
+* points:
  +in+ - the Node is within a polygon.
  +in_or_on+ - it is within or on the edge.
  +on+ - it is on the edge.
-"lines":
- +all+ - part of the Way is within the polygon(s), none is outside; it might touch an edge. 
+
+* lines:
+ +all+ - part of the Way is within the polygon(s), none is outside; it might touch an edge.
  +all_in_or_on+ - none is outside. This is useful for the negative - is_in(...,all_in_or_on)=false - for processing a line that is outside the polgon(s).
  +on+ - it runs along the edge.
  +any+ - part is within.
  +any_in_or_on+ - part is within or in the edge.
-"polygons":
+
+* polygons:
  +all+ - all of the closed Way is within the polygon(s).
- +any" - some is within.
+ +any+ - some is within.
 
 |
 
Index: src/uk/me/parabola/mkgmap/osmstyle/function/IsInFunction.java
===
--- src/uk/me/parabola/mkgmap/osmstyle/function/IsInFunction.java	(revision 4445)
+++ src/uk/me/parabola/mkgmap/osmstyle/function/IsInFunction.java	(working copy)
@@ -22,6 +22,7 @@
 
 import uk.me.parabola.imgfmt.app.Area;
 import uk.me.parabola.imgfmt.app.Coord;
+import uk.me.parabola.log.Logger;
 import uk.me.parabola.mkgmap.reader.osm.Element;
 import uk.me.parabola.mkgmap.reader.osm.ElementSaver;
 import uk.me.parabola.mkgmap.reader.osm.FeatureKind;
@@ -37,7 +38,8 @@
  * @author Ticker Berkin
  *
  */
-public class IsInFunction extends StyleFunction {
+public class IsInFunction extends CachedFunction { // StyleFunction
+	private static final Logger log = Logger.getLogger(IsInFunction.class);
 
 	private enum MethodArg {
 
@@ -91,10 +93,10 @@
 	private class CanStopProcessing extends RuntimeException {};
 
 	private MethodArg method;
-	private boolean hasIn = false;
-	private boolean hasOn = false;
-	private boolean hasOut = false;
-	private ElementQuadTree qt;
+	private boolean hasIn;
+	private boolean hasOn;
+	private boolean hasOut;
+	private ElementQuadTree qt = null;
 
 	public IsInFunction() {
 		super(null);
@@ -102,10 +104,22 @@
 		// 1: polygon tagName
 		// 2: value for above tag
 		// 3: method keyword, see above
+		log.info("isInFunction", System.identityHashCode(this));
 	}
 
+	private void resetHasFlags() {
+		// the instance is per unique call in rules, then applied repeatedly to each point/line/polygon
+		hasIn = false;
+		hasOn = false;
+		hasOut = false;
+	}
+
 	protected String calcImpl(Element el) {
-		if (qt == null || qt.isEmpty())
+		log.info("calcImpl", System.identityHashCode(this), kind, params, el);
+		assert qt != null : "invoked the non-augmented instance";
+		resetHasFlags();
+
+		if (qt.isEmpty())
 			return String.valueOf(false);
 		try {
 			switch (kind) {
@@ -120,17 +134,21 @@
 break;
 			}
 		} catch (CanStopProcessing e) {}
+		log.info("done", hasIn, hasOn, hasOut);
 		return String.valueOf(mapHasFlagsAnswer());
 	}
 
+/* don't have this for CachedFunction
 	@Override
 	public String value(Element el) {
 		return calcImpl(el);
 	}
-	
+*/
+
 	@Override
 	public void setParams(List params, FeatureKind kind) {
 		super.setParams(params, kind);
+		log.info("setParams", System.identityHashCode(this), kind, params);
 		String methodStr = params.get(2);
 		boolean knownMethod = false;
 		List methodsForKin

Re: [mkgmap-dev] Work on is_in branch

[Ticker Berkin]

Hi Gerd

The re-structuring makes this difficult.

I propose a function in IsInUtilTest with the same interface as
calcInsideness from IsInUtil that somehow drives the real function IsIn
Function to collect and build the IN/ON/OUT intflag.

Ticker

On Wed, 2020-02-12 at 15:28 +, Gerd Petermann wrote:
> Hi Ticker,
> 
> did you run the unit tests? This should download a newer version of
> the samples.
> 
> Gerd
> 
> 
> Von: mkgmap-dev  im Auftrag
> von Ticker Berkin 
> Gesendet: Mittwoch, 12. Februar 2020 16:23
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Work on is_in branch
> 
> Hi Gerd
> 
> Here it is - changes are:
> 
> - Some restructuring with early stopping where possible.
> 
> - Merging polygons for POINT IN/ON test so a point on shared boundary
> becomes IN rather than ON.
> 
> - Not merging polygons when no need.
> 
> - Make the function cacheable, so that there is negligible cost to
> the
> second call:
> highway=path & is_in(landuse, residential, all)=true [0xAA]
> highway=path & is_in(landuse, residential, all)=false [0xBB]
> 
> - Improved the layout of documentation in the Style Manual.
> 
> - Fixed quite a few problems.
> 
> I've left quite a lot of debug in for the moment, I think there will
> still be work to do.
> 
> It gives correct answers to 'point-on.osm'. I haven't worked through
> is
> -in-hook-sample-v3.osm yet because I wanted to get this revision out
> to
> replace faults in the previous versions.
> 
> Ticker
> 
> On Tue, 2020-02-11 at 15:49 +, Gerd Petermann wrote:
> > Hi Ticker,
> > 
> > whatever you plan to do. I moved the code to the lib because it is
> > easier to write a unit test.
> > I would not invest much time to avoid a few tests which only happen
> > in very rare cases. Makes testing more complicated and code less
> > readable.
> > 
> > Gerd
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Work on is_in branch

[Ticker Berkin]

Hi Gerd

Here is the start of it + a couple of changes to the interface of
IsInFunction to make life easier.

I won't be able to finish this tonight so I've fixed the IsInUnitTest
to run using a copied version of calcInsideness, but the start of the
'reverse' version is there, called dev_calcInsideness.

Attached patch supersedes is_in-function_v8b.patch and it would be good
if it can be applied soon so that, for instance, Arndt, could see if it
fixes his problem with context and parameters.

Ticker

On Wed, 2020-02-12 at 15:55 +, Gerd Petermann wrote:
> Hi Ticker,
> 
> I found it difficult to test the real style function, that's why I
> moved all the logic out of it.
> I am looking forward to your solution.
> 
> Gerd
> 
> ________
> Von: mkgmap-dev  im Auftrag
> von Ticker Berkin 
> Gesendet: Mittwoch, 12. Februar 2020 16:47
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Work on is_in branch
> 
> Hi Gerd
> 
> The re-structuring makes this difficult.
> 
> I propose a function in IsInUtilTest with the same interface as
> calcInsideness from IsInUtil that somehow drives the real function
> IsIn
> Function to collect and build the IN/ON/OUT intflag.
> 
> Ticker
> 
> On Wed, 2020-02-12 at 15:28 +, Gerd Petermann wrote:
> > Hi Ticker,
> > 
> > did you run the unit tests? This should download a newer version of
> > the samples.
> > 
> > Gerd
> > 
> > 
> > Von: mkgmap-dev  im Auftrag
> > von Ticker Berkin 
> > Gesendet: Mittwoch, 12. Februar 2020 16:23
> > An: Development list for mkgmap
> > Betreff: Re: [mkgmap-dev] Work on is_in branch
> > 
> > Hi Gerd
> > 
> > Here it is - changes are:
> > 
> > - Some restructuring with early stopping where possible.
> > 
> > - Merging polygons for POINT IN/ON test so a point on shared
> > boundary
> > becomes IN rather than ON.
> > 
> > - Not merging polygons when no need.
> > 
> > - Make the function cacheable, so that there is negligible cost to
> > the
> > second call:
> > highway=path & is_in(landuse, residential, all)=true [0xAA]
> > highway=path & is_in(landuse, residential, all)=false [0xBB]
> > 
> > - Improved the layout of documentation in the Style Manual.
> > 
> > - Fixed quite a few problems.
> > 
> > I've left quite a lot of debug in for the moment, I think there
> > will
> > still be work to do.
> > 
> > It gives correct answers to 'point-on.osm'. I haven't worked
> > through
> > is
> > -in-hook-sample-v3.osm yet because I wanted to get this revision
> > out
> > to
> > replace faults in the previous versions.
> > 
> > Ticker
> > 
> > On Tue, 2020-02-11 at 15:49 +, Gerd Petermann wrote:
> > > Hi Ticker,
> > > 
> > > whatever you plan to do. I moved the code to the lib because it
> > > is
> > > easier to write a unit test.
> > > I would not invest much time to avoid a few tests which only
> > > happen
> > > in very rare cases. Makes testing more complicated and code less
> > > readable.
> > > 
> > > Gerd
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-devIndex: doc/styles/rules.txt
===
--- doc/styles/rules.txt	(revision 4445)
+++ doc/styles/rules.txt	(working copy)
@@ -285,19 +285,22 @@
 |is_in(tag,value,method)   | x | x  |  |
 +true+ if the element is in polygon(s) having the specified +tag+=+value+ according to the +method+, +false+ otherwise.
 The methods available depend on the Style section:
-"points":
+
+* points:
  +in+ - the Node is within a polygon.
  +in_or_on+ - it is within or on the edge.
  +on+ - it is on the edge.
-"lines":
- +all+ - part of the Way is within the polygon(s), none is outside; it might touch an edge. 
+
+* lines:
+ +all+ - part of the Way is within the polygon(s), none is outside; it might touch an edge.
  +all_in_or_on+ - none is outside. This is useful for the negative - is_in(...,all_in_or_on)=false - for processing a line that is outside the polgon(s).
  +on+ - it runs along the edge.
  +any+ - part is within.
  +any_in_or_on+ - part is within or in the edge.
-"polygons":
+
+* polygons:
  +all+ - all of the closed Way is within the polygon(s).
- +any" - some is within.
+ +any+ - some is within.
 
 |
 
Index: src/uk/me/parabola/mkgmap/osmstyle/function/IsInFunction.java
==

Re: [mkgmap-dev] More method options for is_in function

[Ticker Berkin]

Hi Arndt

Can you try http://www.mkgmap.org.uk/download/mkgmap-is-in-r4446.zip

If the method parameter isn't understood, it lists the acceptable
method parameters for the context (points/lines/polygons).

I couldn't reproduce the problem with the previous version I had, and I
couldn't see how the include should have effected anything.

Ticker

On Tue, 2020-02-11 at 19:23 +0100, Arndt Röhrig wrote:
> Hi Ticker,
> 
> i include "access" from lines. It´s one of the first lines.
> Move the is_in command to the line file, mkgmap runs without errors.
> But is_in doesn´t work.
> With r-4428 is the result OK.
> 
> (highway~'motorway|trunk|primary|secondary|tertiary|unclassified|mino
> r|residential|living_street|cycleway|steps') {set isin=n} 
> highway=* & rad!=ja & laufen!=ja & tunnel!=* & bridge!=* & isin!=n &
> is_in(landuse,cemetery,all)=true {set isin=j} 
> ...
> ...
> isin=j {set rad=nein}
> isin=j {set highway=tobadforbike}
> 
> Greets
> Arndt
> 
> P.S.
> My complete style is here:
> https://speichenkarte.de/ "Steuerdateien";
> 
> 
> > Ticker Berkin < rwb-mkg...@jagit.co.uk> hat am 11. Februar 2020 um
> > 16:01 geschrieben:
> > 
> > 
> > Hi Arndt
> > 
> > Are you including inc/access from points?
> > 
> > Ticker
> > 
> > On Tue, 2020-02-11 at 13:54 +0100, Arndt Röhrig wrote:
> > > Hi Ticker,
> > > 
> > > i get this:
> > > 
> > > 13:40:20,54 - mkgmap .\tools\mkgmap-is-in-r4443 Speiche_Fabrik
> > > Error in style: Error: (inc/access:73): Error: Third parameter
> > > 'all'
> > > of function is_in is not supported
> > > 
> > > Reason is, the is_in command is in the access-file :)
> > > 
> > > Thank you
> > > 
> > > Arndt
> > > 
> > > 
> > > 
> > > > Ticker Berkin < rwb-mkg...@jagit.co.uk> hat am 11. Februar 2020
> > > > um
> > > > 13:02 geschrieben:
> > > > 
> > > > 
> > > > 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
> > > > happens?
> > > > 
> > > > But the simple answer to your question is, for a rule in
> > > > "lines" or
> > > > "polygons", what you have written will still work.
> > > > 
> > > > Ticker
> > > > 
> > > > On Tue, 2020-02-11 at 12:32 +0100, Arndt Röhrig wrote:
> > > > > Hi Gerd,
> > > > > 
> > > > > is_in(landuse,residential,all)=true
> > > > > 
> > > > > how do you write that now?
> > > > > 
> > > > > Greets
> > > > > Arndt
> > > > > 
> > > > > > Gerd Petermann < gpetermann_muenc...@hotmail.com> hat am
> > > > > > 10.
> > > > > > Februar 2020 um 14:14 geschrieben:
> > > > > > 
> > > > > > 
> > > > > > Hi all,
> > > > > > 
> > > > > > see
> > > > > > http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap
> > > > > > &rev
> > > > > > =4442
> > > > > > 
> > > > > > @Ticker:
> > > > > > I assume you are working on an alternative implementation
> > > > > > of
> > > > > > the
> > > > > > methods in IsInUtil?
> > > > > > If not I'd like to remove all the code duplication
> > > > > > introduced
> > > > > > with
> > > > > > the last patch.
> > > > > > 
> > > > > > Gerd
> > > > > > ___
> > > > > > mkgmap-dev mailing list
> > > > > > mkgmap-dev@lists.mkgmap.org.uk
> > > > > > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> > > > > ___
> > > > > mkgmap-dev mailing list
> > > > > mkgmap-dev@lists.mkgmap.org.uk
> > > > > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev_
> > > > > 
> > > > > __
> > > > mkgmap-dev mailing list
> > > > mkgmap-dev@lists.mkgmap.org.uk
> > > > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> > > ___
> > > mkgmap-dev mailing list
> > > mkgmap-dev@lists.mkgmap.org.uk
> > > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> > ___
> > mkgmap-dev mailing list
> > mkgmap-dev@lists.mkgmap.org.uk
> > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] More method options for is_in function

[Ticker Berkin]

Hi Arndt

you have an include 'inc/access' in styles_base/points and
styles_gravel/points

which gives the error about unsupported options.

The crash is related: because the calls are textually identical, the
optimiser semi-tries to share them between points and lines processing,
it initializes one instance only, but later the correct ones are called
for the 2 contexts. I introduced this assertion error in the last
update to catch strange things like this happening. Before it would
have quietly returned "false"

Ticker


On Thu, 2020-02-13 at 06:37 +0100, Arndt Röhrig wrote:
> Hi Ticker,
> 
> mkgmap tell me:
> 
> 6:33:39,37 - mkgmap .\tools\mkgmap-is-in-r4446 Speiche_Fabrik 
> Error in style: Error: (inc/access:73): Error: Third parameter 'all'
> of function is_in is not supported for this style section, valid are:
> [in, in_or_on, on] 
> Error in style: Error: (inc/access:73): Error: Third parameter 'all'
> of function is_in is not supported for this style section, valid are:
> [in, in_or_on, on] 
> Error in style: Error: (inc/access:73): Error: Third parameter 'all'
> of function is_in is not supported for this style section, valid are:
> [in, in_or_on, on] 
> Error in style: Error: (inc/access:73): Error: Third parameter 'all'
> of function is_in is not supported for this style section, valid are:
> [in, in_or_on, on] 
> Could not open style
> 
> 
> If i move the "is_in" command to the line file, mkgmap say:
> 
> 6:30:43,78 - mkgmap .\tools\mkgmap-is-in-r4446 Speiche_Fabrik 
> java.lang.AssertionError: invoked the non-augmented instance 
> at
> uk.me.parabola.mkgmap.osmstyle.function.IsInFunction.calcImpl(IsInFun
> ction.java:119) 
> at
> uk.me.parabola.mkgmap.osmstyle.function.CachedFunction.value(CachedFu
> nction.java:61) 
> at
> uk.me.parabola.mkgmap.osmstyle.eval.EqualsOp.eval(EqualsOp.java:33) 
...

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] More method options for is_in function

[Ticker Berkin]

Hi Gerd

I overrode getCacheTag() to fix this aspect, and you overrode
toString() for something relating to the common sub-expressions; in
both cases including the 'kind' and all the parameters.

Yesterday, experimenting, I found it was consistent about create 2
instances, augmenting the same one twice and then using just that one
for the actual work, but this was when the calls were in the same
section. So, sometime I should investigate what happen when there valid
identical calls in 2 sections.

Ticker

On Thu, 2020-02-13 at 09:53 +, Gerd Petermann wrote:
> Hi Ticker,
> 
> I think CachedFunction can't be used without changes. It uses
> getName() which just returns "is_in" (no parameters).
> 
> Gerd
> 
> ____
> Von: mkgmap-dev  im Auftrag
> von Ticker Berkin 
> Gesendet: Donnerstag, 13. Februar 2020 10:26
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] More method options for is_in function
> 
> Hi Arndt
> 
> you have an include 'inc/access' in styles_base/points and
> styles_gravel/points
> 
> which gives the error about unsupported options.
> 
> The crash is related: because the calls are textually identical, the
> optimiser semi-tries to share them between points and lines
> processing,
> it initializes one instance only, but later the correct ones are
> called
> for the 2 contexts. I introduced this assertion error in the last
> update to catch strange things like this happening. Before it would
> have quietly returned "false"
> 
> Ticker
> 
> 
> On Thu, 2020-02-13 at 06:37 +0100, Arndt Röhrig wrote:
> > Hi Ticker,
> > 
> > mkgmap tell me:
> > 
> > 6:33:39,37 - mkgmap .\tools\mkgmap-is-in-r4446 Speiche_Fabrik
> > Error in style: Error: (inc/access:73): Error: Third parameter
> > 'all'
> > of function is_in is not supported for this style section, valid
> > are:
> > [in, in_or_on, on]
> > Error in style: Error: (inc/access:73): Error: Third parameter
> > 'all'
> > of function is_in is not supported for this style section, valid
> > are:
> > [in, in_or_on, on]
> > Error in style: Error: (inc/access:73): Error: Third parameter
> > 'all'
> > of function is_in is not supported for this style section, valid
> > are:
> > [in, in_or_on, on]
> > Error in style: Error: (inc/access:73): Error: Third parameter
> > 'all'
> > of function is_in is not supported for this style section, valid
> > are:
> > [in, in_or_on, on]
> > Could not open style
> > 
> > 
> > If i move the "is_in" command to the line file, mkgmap say:
> > 
> > 6:30:43,78 - mkgmap .\tools\mkgmap-is-in-r4446 Speiche_Fabrik
> > java.lang.AssertionError: invoked the non-augmented instance
> > at
> > uk.me.parabola.mkgmap.osmstyle.function.IsInFunction.calcImpl(IsInF
> > un
> > ction.java:119)
> > at
> > uk.me.parabola.mkgmap.osmstyle.function.CachedFunction.value(Cached
> > Fu
> > nction.java:61)
> > at
> > uk.me.parabola.mkgmap.osmstyle.eval.EqualsOp.eval(EqualsOp.java:33)
> ...
> 
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Fwd: Re: AW: More method options for is_in function

[Ticker Berkin]

Hi Arndt

I can reproduce this - it seem to be something related to the
expression structure.

Probably it just returned 'false' before, rather than raising the
exception.

I'll investigate

Ticker 

On Thu, 2020-02-13 at 16:38 +0100, Arndt Röhrig wrote:
> > Hi Gerd, hi Ticker,
> > 
> > now i use is-in-r-4449. Sorry, some mistakes happen without
> > explanation.
> > 
> > 4449 report this:
> > 
> > Greets
> > Arndt
> > 
> > 16:24:37,71 - mkgmap .\tools\mkgmap-is-in-r4449 Speiche_Fabrik 
> > java.lang.AssertionError: invoked the non-augmented instance 
> > at uk.me.parabola.mkgmap.osmstyle.function.IsInFunction.calcImpl(Is
> > c
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Fwd: Re: AW: More method options for is_in function

[Ticker Berkin]

Hi Arndt, Gerd

Sorry - this was me mis-reading the code and is simply fixed.
The assertion failed when there are no polygons in the tile that match
the tag/key.

patch attached

Ticker

On Thu, 2020-02-13 at 16:39 +, Ticker Berkin wrote:
> Hi Arndt
> 
> I can reproduce this - it seem to be something related to the
> expression structure.
> 
> Probably it just returned 'false' before, rather than raising the
> exception.
> 
> I'll investigate
> 
> Ticker 
> 
> On Thu, 2020-02-13 at 16:38 +0100, Arndt Röhrig wrote:
> > > Hi Gerd, hi Ticker,
> > > 
> > > now i use is-in-r-4449. Sorry, some mistakes happen without
> > > explanation.
> > > 
> > > 4449 report this:
> > > 
> > > Greets
> > > Arndt
> > > 
> > > 16:24:37,71 - mkgmap .\tools\mkgmap-is-in-r4449 Speiche_Fabrik 
> > > java.lang.AssertionError: invoked the non-augmented instance 
> > > at
> > > uk.me.parabola.mkgmap.osmstyle.function.IsInFunction.calcImpl(Is
> > > c
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-devIndex: src/uk/me/parabola/mkgmap/osmstyle/function/IsInFunction.java
===
--- src/uk/me/parabola/mkgmap/osmstyle/function/IsInFunction.java	(revision 4450)
+++ src/uk/me/parabola/mkgmap/osmstyle/function/IsInFunction.java	(working copy)
@@ -117,10 +117,9 @@
 	public String calcImpl(Element el) {
 		log.info("calcImpl", System.identityHashCode(this), kind, params, el);
 		assert qt != null : "invoked the non-augmented instance";
-		resetHasFlags();
-
 		if (qt.isEmpty())
 			return String.valueOf(false);
+		resetHasFlags();
 		try {
 			switch (kind) {
 			case POINT:
@@ -134,7 +133,7 @@
 break;
 			}
 		} catch (CanStopProcessing e) {}
-		log.info("done", hasIn, hasOn, hasOut);
+		log.info("done", System.identityHashCode(this), hasIn, hasOn, hasOut);
 		return String.valueOf(mapHasFlagsAnswer());
 	}
 
@@ -304,7 +303,17 @@
 			}
 		}
 	}
+/*
+make above function return boolean depending on it finding something.
+maybe should also respond to ON
 
+in below, delay setting the IN flag until have done the above, because the line could all be ON the inner.
+and use return from above to set IN, assume that when it finds something, it will set IN of OUT etc
+
+for POLY, still need a final check that, even if ON/IN, none of the holes is in this one, so
+we need another check (can we use above not-in-hole...) that takes a point from the hole and
+checks if it is the polyLine
+ */
 	private void doCommonTest(Element el) {
 		List polyLine = ((Way)el).getPoints();
 		Area elementBbox = Area.getBBox(polyLine);
@@ -388,10 +397,7 @@
 }
 			}
 		}
-		if (!matchingPolygons.isEmpty()) {
-			return new ElementQuadTree(elementSaver.getBoundingBox(), matchingPolygons);
-		}
-		return null;
+		return new ElementQuadTree(elementSaver.getBoundingBox(), matchingPolygons);
 	}
 
 	public void unitTestAugment(ElementQuadTree qt) {
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] errors in typ file

[Ticker Berkin]

Hi

Is this using something based on resources/typ-files/mapnik.txt

My guessing of a translation of the error messages you are getting is
that TYPviewer defaults the output code-page to 1252 and then doesn't
like various strings that can't be represented in that code page.
Try uncommenting the line: CodePage=65001

Having this line will cause harmless warnings from mkgmap when you
generate a non-unicode map

Ticker

On Sat, 2020-02-15 at 08:44 +0100, Arndt Röhrig wrote:
> Good morning,
> 
> i use TYPViewer for my typ files. This program reports some errors,
> when i open a type file.
> 
> My typs are .txt files. So far they are ok. In a first step i use
> mkgmap to create .typ files. It runs without error messages. The map
> seems to be OK. But when i open a typ file with TYPViewer the error
> messages appear. When i edit an element, TYPViewer pop up an error
> message and close.
> 
> i guess the changes in r-4437 do that? Is there something wrong in my
> typs?
> For example the polygone 0x0e:
> 
> [_polygon] 
> Type=0x0e 
> ;GRMN_TYPE: Large Manmade Areas/AIRPORT_RUNWAYS/Airport runway
> area/Non NT 
> String1=0x02,Bürogewerbe 
> ExtendedLabels=Y 
> FontStyle=NoLabel (invisible) 
> CustomColor=No 
> Xpm="0 0 1 0" 
> "1 c #F2D9D8" 
> [end]
> 
> Greets 
> 
> Arndt
> 
> 
> P.S. The error message from TYPViewer:
> 
> 
> 
> *
> *
> 
> Fehler in der Datei :
> C:\ProgramData\GARMIN\Maps\Speiche_Fabrik_Gravel.gmap\Speiche.typ 
> *
> *
> 
> 
> Unbekannte CodePage-Nummer: 0 
> TYPViewer ersetzte die CodePage mit 1252 
> Wenn dies nicht paßt, wähle eine andere CodePage-Nummer in der
> Auswahlbox "CodePage" 
> Problem beim Lesen der Strings des Polygons Type=0x004 SubTypes =
> 0x00 
> Problem beim Lesen der Strings des Polygons Type=0x00e SubTypes =
> 0x00 
> Problem beim Lesen der Strings des Polygons Type=0x010 SubTypes =
> 0x00 
> Problem beim Lesen der Strings des Polygons Type=0x014 SubTypes =
> 0x00 
> Problem beim Lesen der Strings des Polygons Type=0x01c SubTypes =
> 0x00 
> Problem beim Lesen der Strings des Polygons Type=0x04e SubTypes =
> 0x00 
> Problem beim Lesen der Strings des Polygons Type=0x054 SubTypes =
> 0x00 
> Problem beim Lesen der Strings der Polylinie Type=0x015 SubTypes =
> 0x00 
> Problem beim Lesen der Strings des POI Type=0x001 SubTypes = 0x00
>  
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] errors in typ file

[Ticker Berkin]

Hi Arndt

Looking back at the first posting, the messages seem to be from
TYPViewer on the .typ file rather than the .txt file.

What codepage are your TYP .txt files written in? It looks like 1252.
How did you generate the .typ from the .txt? If mkgmap, what command
line --code-page did you have? (or --charset). When using mkgmap to
convert .txt to .typ, the --code-page overrides any CodePage= line in
the .txt file.

It is possible that this is where there has been a change. No --code
-page specified to mkgmap defaults the map.img to ascii/cp0 I think,
but maybe the typ file used to default to its value of 'CodePage', but
now uses the mkgmap value. 

The messages TYPview is giving could be because it considers the code
-page to be 7-bit ASCII but it is finding strings with the top bit set.

This all seems to fit when what you've just said. When using mkgmap to
convert your .txt, use the same --code-page as you will for your final
maps.

Ticker

On Sat, 2020-02-15 at 13:10 +0100, Arndt Röhrig wrote:
> Hi Ticker,
> 
> "and then doesn't
> like various strings that can't be represented in that code page."
> 
> That brings me to the idea to look at "ä ö ü" in my typ file. When i
> kill this, it works better :)
> 
> Now, TYPViewer says only this:
> Unbekannte CodePage-Nummer: 0 
> TYPViewer ersetzte die CodePage mit 1252 
> 
> When i set the option --latin1 in mkgmap this message is gone. It
> seems, that mkgmap ignore the codepage line in the typ-file?
> 
> No matter, i know now, what to do, even tough i don´t understand why
> :)
> 
> Thank you for helping me!
> 
> Greets
> Arndt
> 
> 
> 
> > Ticker Berkin < rwb-mkg...@jagit.co.uk> hat am 15. Februar 2020 um
> > 12:00 geschrieben:
> > 
> > 
> > Hi
> > 
> > Is this using something based on resources/typ-files/mapnik.txt
> > 
> > My guessing of a translation of the error messages you are getting
> > is
> > that TYPviewer defaults the output code-page to 1252 and then
> > doesn't
> > like various strings that can't be represented in that code page.
> > Try uncommenting the line: CodePage=65001
> > 
> > Having this line will cause harmless warnings from mkgmap when you
> > generate a non-unicode map
> > 
> > Ticker
> > 
> > On Sat, 2020-02-15 at 08:44 +0100, Arndt Röhrig wrote:
> > > Good morning,
> > > 
> > > i use TYPViewer for my typ files. This program reports some
> > > errors,
> > > when i open a type file.
> > > 
> > > My typs are .txt files. So far they are ok. In a first step i use
> > > mkgmap to create .typ files. It runs without error messages. The
> > > map
> > > seems to be OK. But when i open a typ file with TYPViewer the
> > > error
> > > messages appear. When i edit an element, TYPViewer pop up an
> > > error
> > > message and close.
> > > 
> > > i guess the changes in r-4437 do that? Is there something wrong
> > > in my
> > > typs?
> > > For example the polygone 0x0e:
> > > 
> > > [_polygon]
> > > Type=0x0e
> > > ;GRMN_TYPE: Large Manmade Areas/AIRPORT_RUNWAYS/Airport runway
> > > area/Non NT
> > > String1=0x02,Bürogewerbe
> > > ExtendedLabels=Y
> > > FontStyle=NoLabel (invisible)
> > > CustomColor=No
> > > Xpm="0 0 1 0"
> > > "1 c #F2D9D8"
> > > [end]
> > > 
> > > Greets
> > > 
> > > Arndt
> > > 
> > > 
> > > P.S. The error message from TYPViewer:
> > > 
> > > 
> > > 
> > > *
> > > 
> > > *
> > > 
> > > 
> > > Fehler in der Datei :
> > > C:\ProgramData\GARMIN\Maps\Speiche_Fabrik_Gravel.gmap\Speiche.typ
> > > *
> > > 
> > > *
> > > 
> > > 
> > > 
> > > Unbekannte CodePage-Nummer: 0
> > > TYPViewer ersetzte die CodePage mit 1252
> > > Wenn dies nicht paßt, wähle eine andere CodePage-Nummer in der
> > > Auswahlbox "CodePage"
> > > Problem beim Lesen der Strings des Polygons Type=0x004 SubTypes =
> > > 0x00
> > > Problem beim Lesen der Strings des Polygons Type=0x00e SubTypes =
> > > 0x00
> > > Problem beim 

Re: [mkgmap-dev] Work on is_in branch

[Ticker Berkin]

Hi Gerd

Here is patch with:
- IsInUtilTest driver using the is_in function with methods.
- a slight re-formulation to the 'any_in_or_in' method.
- updates to style manual for above.
- some fixes and improvements relating to holes, ON etc.

There is one more bit of logic that is needed for polygons: after the
polygon has been found to be fully within a shape, and it isn't in a
hole, check that a hole isn't within it. I'll so this in the next day
or so.

I'm having trouble with b14 (building is inner to a multi-polygon):
Without merging the cut outer, isLineInShape for the b14 polygon
returns IN/ON/OUT for the first component - I was expecting ON/OUT.
With merging, it returns IN for the merged shape (good), but IN/ON for
the hole - I was expecting ON.

Ticker

On Wed, 2020-02-12 at 15:55 +, Gerd Petermann wrote:
> Hi Ticker,
> 
> I found it difficult to test the real style function, that's why I
> moved all the logic out of it.
> I am looking forward to your solution.
> 
> Gerd
> 
> ________
> Von: mkgmap-dev  im Auftrag
> von Ticker Berkin 
> Gesendet: Mittwoch, 12. Februar 2020 16:47
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Work on is_in branch
> 
> Hi Gerd
> 
> The re-structuring makes this difficult.
> 
> I propose a function in IsInUtilTest with the same interface as
> calcInsideness from IsInUtil that somehow drives the real function
> IsIn
> Function to collect and build the IN/ON/OUT intflag.
> 
> Ticker
> 
> On Wed, 2020-02-12 at 15:28 +, Gerd Petermann wrote:
> > Hi Ticker,
> > 
> > did you run the unit tests? This should download a newer version of
> > the samples.
> > 
> > Gerd
> > 
> > 
> > Von: mkgmap-dev  im Auftrag
> > von Ticker Berkin 
> > Gesendet: Mittwoch, 12. Februar 2020 16:23
> > An: Development list for mkgmap
> > Betreff: Re: [mkgmap-dev] Work on is_in branch
> > 
> > Hi Gerd
> > 
> > Here it is - changes are:
> > 
> > - Some restructuring with early stopping where possible.
> > 
> > - Merging polygons for POINT IN/ON test so a point on shared
> > boundary
> > becomes IN rather than ON.
> > 
> > - Not merging polygons when no need.
> > 
> > - Make the function cacheable, so that there is negligible cost to
> > the
> > second call:
> > highway=path & is_in(landuse, residential, all)=true [0xAA]
> > highway=path & is_in(landuse, residential, all)=false [0xBB]
> > 
> > - Improved the layout of documentation in the Style Manual.
> > 
> > - Fixed quite a few problems.
> > 
> > I've left quite a lot of debug in for the moment, I think there
> > will
> > still be work to do.
> > 
> > It gives correct answers to 'point-on.osm'. I haven't worked
> > through
> > is
> > -in-hook-sample-v3.osm yet because I wanted to get this revision
> > out
> > to
> > replace faults in the previous versions.
> > 
> > Ticker
> > 
> > On Tue, 2020-02-11 at 15:49 +, Gerd Petermann wrote:
> > > Hi Ticker,
> > > 
> > > whatever you plan to do. I moved the code to the lib because it
> > > is
> > > easier to write a unit test.
> > > I would not invest much time to avoid a few tests which only
> > > happen
> > > in very rare cases. Makes testing more complicated and code less
> > > readable.
> > > 
> > > Gerd
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-devIndex: doc/styles/rules.txt
===
--- doc/styles/rules.txt	(revision 4453)
+++ doc/styles/rules.txt	(working copy)
@@ -286,19 +286,19 @@
 +true+ if the element is in polygon(s) having the specified +tag+=+value+ according to the +method+, +false+ otherwise.
 The methods available depend on the Style section:
 
-* points:
+. points:
  +in+ - the Node is within a polygon.
  +in_or_on+ - it is within or on the edge.
  +on+ - it is on the edge.
 
-* lines:
+. lines:
  +all+ - part of the Way is within the polygon(s), none is outside; it might touch an edge.
- +all_in_or_on+ - none is outside. This is useful for the negative - is_in(...,all_in_or_on)=false - for processing a line that is outside the polgon(s).
+ +all_in_or_on+ - none is outside.
  +on+ - it runs along the edge.
  +any+ - part is within.
- +any_in_or_on+ - part is within or in the edge.
+ +any_in_or_on+ - part is within or all is on the edge. This is us

Re: [mkgmap-dev] errors in typ file

[Ticker Berkin]

Hi Arndt

There should be no need to delete äöü if you use the --latin1 or
--code-page=1252 option to mkgmap

Ticker

On Sat, 2020-02-15 at 14:31 +0100, Arndt Röhrig wrote:
> Hi Ticker,
> 
> now all is OK. I delete äöü in the typ/txt files and give mkgmap the
> option --latin1. 
> 
> Thank you!
> 
> 
> Greets
> 
> Arndt
> > Ticker Berkin < rwb-mkg...@jagit.co.uk> hat am 15. Februar 2020 um
> > 14:03 geschrieben:
> > 
> > 
> > Hi Arndt
> > 
> > Looking back at the first posting, the messages seem to be from
> > TYPViewer on the .typ file rather than the .txt file.
> > 
> > What codepage are your TYP .txt files written in? It looks like
> > 1252.
> > How did you generate the .typ from the .txt? If mkgmap, what
> > command
> > line --code-page did you have? (or --charset). When using mkgmap to
> > convert .txt to .typ, the --code-page overrides any CodePage= line
> > in
> > the .txt file.
> > 
> > It is possible that this is where there has been a change. No -
> > -code
> > -page specified to mkgmap defaults the map.img to ascii/cp0 I
> > think,
> > but maybe the typ file used to default to its value of 'CodePage',
> > but
> > now uses the mkgmap value.
> > 
> > The messages TYPview is giving could be because it considers the
> > code
> > -page to be 7-bit ASCII but it is finding strings with the top bit
> > set.
> > 
> > This all seems to fit when what you've just said. When using mkgmap
> > to
> > convert your .txt, use the same --code-page as you will for your
> > final
> > maps.
> > 
> > Ticker
> > 
> > On Sat, 2020-02-15 at 13:10 +0100, Arndt Röhrig wrote:
> > > Hi Ticker,
> > > 
> > > "and then doesn't
> > > like various strings that can't be represented in that code
> > > page."
> > > 
> > > That brings me to the idea to look at "ä ö ü" in my typ file.
> > > When i
> > > kill this, it works better :)
> > > 
> > > Now, TYPViewer says only this:
> > > Unbekannte CodePage-Nummer: 0
> > > TYPViewer ersetzte die CodePage mit 1252
> > > 
> > > When i set the option --latin1 in mkgmap this message is gone. It
> > > seems, that mkgmap ignore the codepage line in the typ-file?
> > > 
> > > No matter, i know now, what to do, even tough i don´t understand
> > > why
> > > :)
> > > 
> > > Thank you for helping me!
> > > 
> > > Greets
> > > Arndt
> > > 
> > > 
> > > 
> > > > Ticker Berkin < rwb-mkg...@jagit.co.uk> hat am 15. Februar 2020
> > > > um
> > > > 12:00 geschrieben:
> > > > 
> > > > 
> > > > Hi
> > > > 
> > > > Is this using something based on resources/typ-files/mapnik.txt
> > > > 
> > > > My guessing of a translation of the error messages you are
> > > > getting
> > > > is
> > > > that TYPviewer defaults the output code-page to 1252 and then
> > > > doesn't
> > > > like various strings that can't be represented in that code
> > > > page.
> > > > Try uncommenting the line: CodePage=65001
> > > > 
> > > > Having this line will cause harmless warnings from mkgmap when
> > > > you
> > > > generate a non-unicode map
> > > > 
> > > > Ticker
> > > > 
> > > > On Sat, 2020-02-15 at 08:44 +0100, Arndt Röhrig wrote:
> > > > > Good morning,
> > > > > 
> > > > > i use TYPViewer for my typ files. This program reports some
> > > > > errors,
> > > > > when i open a type file.
> > > > > 
> > > > > My typs are .txt files. So far they are ok. In a first step i
> > > > > use
> > > > > mkgmap to create .typ files. It runs without error messages.
> > > > > The
> > > > > map
> > > > > seems to be OK. But when i open a typ file with TYPViewer the
> > > > > error
> > > > > messages appear. When i edit an element, TYPViewer pop up an
> > > > > error
> > > > > message and close.
> > > > > 
> > > > > i guess the changes in r-4437 do that? Is there something
> > > > > wrong
> > > > > in my
> > > > > typs?
> > > > > For example the 

Re: [mkgmap-dev] Work on is_in branch

[Ticker Berkin]

Hi Gerd

The new meaning of any_in_or_on is for handing a line where some is
OUT, none is IN and touching the edge is irrelevant and is tested as
()=false, with the +ve logic being "some-IN or all-ON". Can't stop on
ON because need to have IN component.

This was the the meaning I had originally intended, but at some point
forgot. It is the reciprocal of the method for a line where some is IN
and touching the edge makes no difference.

Various timing tests on a 2 tile area with max-jobs=1, my normal
options and a function invocation in lines.

These are with my latest code:

highway=* & length()<200 {add maxspeed="20 mph"}
Total time taken: 1 minute 12 seconds

highway=* & is_in(landuse,residential,any)=true {add maxspeed="20 mph"}
Total time taken: 1 minute 14 seconds

..., all)...
Total time taken: 1 minute 23 seconds

..., on)...
Total time taken: 1 minute 21 seconds


Taking out the automatic "stop early" code, timings are:

highway=* & is_in(landuse,residential,any)=true {add maxspeed="20 mph"}

Total time taken: 1 minute 17 seconds

..., all)...
Total time taken: 1 minute 24 seconds

..., on)...
Total time taken: 1 minute 23 seconds

ie the "stop-early" gives a slight improvement for "all"/"on" and a bigger 
improvement for "any"

I feel the "stop-early" mechanism is well hidden from the much more complex 
coding of isLineInShape() and how the results of this should be interpreted 
with multiple shapes and holes, etc, and so it is worth-while. 

I'm getting strange results for b14 just from the 2 parts of the outer after MP 
cutting, without the Java2D logic in mergePolygons being invoked. I'll 
investigate.

Ticker

On Mon, 2020-02-17 at 11:33 +, Gerd Petermann wrote:
> Hi Ticker,
> 
> I don't understand the new meaning of any_in_or_on. Why can't you
> stop early when ON was found?
> 
> I still think that the "stop early" code is just adding complexity.
> Do you have a sample that shows how this improves performance?
> 
> Reg. unexpected results when joining shapes: Welcome to the club!
> Some not so obvious things:
> - The java area code sometimes removes points which are on straight
> lines.
> - a node calculated with e.g. makeBetweenPoint is only very close to
> the place where it should be
> 
> Gerd
> 
> 
> Von: mkgmap-dev  im Auftrag
> von Ticker Berkin 
> Gesendet: Montag, 17. Februar 2020 11:31
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Work on is_in branch
> 
> Hi Gerd
> 
> Here is patch with:
> - IsInUtilTest driver using the is_in function with methods.
> - a slight re-formulation to the 'any_in_or_in' method.
> - updates to style manual for above.
> - some fixes and improvements relating to holes, ON etc.
> 
> There is one more bit of logic that is needed for polygons: after the
> polygon has been found to be fully within a shape, and it isn't in a
> hole, check that a hole isn't within it. I'll so this in the next day
> or so.
> 
> I'm having trouble with b14 (building is inner to a multi-polygon):
> Without merging the cut outer, isLineInShape for the b14 polygon
> returns IN/ON/OUT for the first component - I was expecting ON/OUT.
> With merging, it returns IN for the merged shape (good), but IN/ON
> for
> the hole - I was expecting ON.
> 
> Ticker
> 
> On Wed, 2020-02-12 at 15:55 +, Gerd Petermann wrote:
> > Hi Ticker,
> > 
> > I found it difficult to test the real style function, that's why I
> > moved all the logic out of it.
> > I am looking forward to your solution.
> > 
> > Gerd
> > 
> > 
> > Von: mkgmap-dev  im Auftrag
> > von Ticker Berkin 
> > Gesendet: Mittwoch, 12. Februar 2020 16:47
> > An: Development list for mkgmap
> > Betreff: Re: [mkgmap-dev] Work on is_in branch
> > 
> > Hi Gerd
> > 
> > The re-structuring makes this difficult.
> > 
> > I propose a function in IsInUtilTest with the same interface as
> > calcInsideness from IsInUtil that somehow drives the real function
> > IsIn
> > Function to collect and build the IN/ON/OUT intflag.
> > 
> > Ticker
> > 
> > On Wed, 2020-02-12 at 15:28 +, Gerd Petermann wrote:
> > > Hi Ticker,
> > > 
> > > did you run the unit tests? This should download a newer version
> > > of
> > > the samples.
> > > 
> > > Gerd
> > > 
> > > 
> > > Von: mkgmap-dev  im
> > > Auftrag
> > > von Ticker Berkin 
> >

Re: [mkgmap-dev] Work on is_in branch

[Ticker Berkin]

Hi Gerd

A simpler way of expressing it in the Style Manual would be:

 +any_in_or_on+ - if is_in(...,any_in_or_on)=false, part is outside,
none is inside.

What do you think? An alternative would be to re-phrase the keyword as
something like 'some-out-none-in', testing for =true instead. But, with
the function being called 'is_in', I wanted to have the methods
expressing IN'ness as far as possible.

Rec. early-stop. It has ~4% improvement for 'any' in my scenario, ~2.5%
for 'on' and ~1% for all.
It just seems easy and sensible to stop when, if asking for 'any', a
part is found IN, or, if asking for 'all', a part is found OUT, etc

Ticker

On Mon, 2020-02-17 at 17:13 +, Gerd Petermann wrote:
> Hi Ticker,
> 
> reg. result:
> Please find a better explanation for this:
> "This is useful for the negative - is_in(...,any_in_or_on)=false -
> for processing a line that is outside the polgon(s) but might touch
> an edge."
> For me this sounds plain wrong. It would be okay without "but might
> touch an edge".
> 
> reg. performance:
> I did not mean to remove early stop completely, I just don't believe
> that it is worth to distinguish the different methods.
> My original code also stops early when result is 7 (IN+ON+OUT).
> 
> reg. special case b14: one reason why I don't like my code. It's
> frustrating. OTOH nobody seems to care about the results for
> polygons.
> 
> Gerd

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Dead end check

[Ticker Berkin]

Hi

It is standard mkgmap behaviour to not load OSM tags that it doesn't
see the need for. It detects tags referenced in the style and has a
list of other tags known to be processed by the java code
(resources/styles/builtin-tag-list).

Add extra ones to your style options file:
...
extra-used-tags=mkgmap:dead-end-check,etc,etc

or equiv command line option.

Ticker

On Mon, 2020-02-17 at 19:17 +, Mike Baggaley wrote:
> Hi all,
> 
> I have set logging to enable warnings in StyledConverter, and have
> been
> getting a few unexpected results from the dead end check. It seems
> that
> using the default style and latest mkgmap release, if a way has
> mkgmap:dead-end-check=no set in OSM, this information is not loaded,
> so when
> the dead end check is run, ways with this tag are not omitted from
> the
> check. I have worked around this by adding a dummy line to the lines
> file:
> 
> mkgmap:dead-end-check=no {set mkgmap:dead-end-check=no}
> 
> The tag data is then loaded.
> 
> It seems to me though that the code should include mkgmap:dead-end
> -check in
> the list of standard tags to be loaded, without needing anything
> specific in
> the style (or at least if dead end check is enabled). I would not
> expect OSM
> to have many of these, so it should not make any significant
> difference to
> the amount of memory needed by mkgmap or affect the execution time.
> 
> An example is way  108322149 which is one of the ways where cars get
> on the
> train at Ashford.
> 
> I suspect the same thing will happen with mkgmap:flare-check,
> mkgmap:dir-check and mkgmap:no-dir-check.
> 
> Regards,
> Mike
> 
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Work on is_in branch

[Ticker Berkin]

Hi Gerd

The two most common cases that I imagine users will want to match are
lines inside the polygon(s) and lines outside.

Inside lines will frequently meet the edge, and I don't think these
should fail the inside test.

Outside lines will, less frequently, meet the edge, and I don't think
these should fail the outside test.

Often there will be 2 lines, joining at edge of the polygon, that make
a continuous highway that is the entrance to the polygon. Both of these
will have an ON component.

So, the flag test for inside lines should be "hasIn && !hasOut" and for
outside lines should be "hasOut && !hasIn".

Expressing the outside test as the negative, in keeping with the
is_in() methods expressing in-ness, it becomes "hasIn || !hasOut".
I had expressed this as "hasIn || !(hasIn || hasOut)", because "!(hasIn
|| hasOut)" is all_ON, and this matches the method being called,
ambiguously, ANY_IN_OR_ON (ON_OR_ANY_IN would have been better) but
they are logically equivalent.

This expressing as in-ness seems to be the cause of these problems we
are discussing and maybe now is the time to abandon it.

I suggest replacing ANY_IN_OR_ON with SOME_OUT_NONE_IN, giving it the
method string "none", like SOME_IN_NONE_OUT is referenced as "all".

Ticker

On Mon, 2020-02-17 at 19:16 +, Gerd Petermann wrote:
> Hi Ticker,
> 
> I would except
>  +any_in_or_on+ - if is_in(...,any_in_or_on)=false, all is outside,
> none is in or on the edge.
> 
> Or name it
> +all_out+ - if is_in(...,all_out)=true, all is outside, none is in or
> on the edge.
> 
> A method that returns true when all is either out or on the edge
> could be called
> +out-or-on+
> 
> Gerd

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Work on is_in branch

[Ticker Berkin]

Hi Gerd

Part of the reason for the methods is to group the IN/ON/OUT cases
together in various combinations for meaningful usability.

In IsInUtilTest.java is the table (for the sake of brevity, using
'camel' notation rather than underscores as in the actual method
keyword):
/* all=someInNoneOut, any=anyIn, none=someOutNoneIn
a) INall allInOrOnany
b) IN ON all allInOrOnany
c) IN ON OUT  any
d)ON allInOrOn on
e)ON OUT  none
f)   OUT  none
*/

So the difference between ..,all)=true and ..,none)=false is what
happens to cases c) and d).

The methods "any", "on" and "allInOrOn" include these cases. Obvious
and sensible for the meaning of "any" and "on", "allInOrOn" is a bit
arbritary, but the idea is that a perimeter line can be picked up along
with the inside lines in one test if that is what is wanted. I didn't
think there was a need to pick up a perimeter line with the outside
lines, but this could be added easily.

Ticker

On Tue, 2020-02-18 at 00:28 -0700, Gerd Petermann wrote:
> Gerd Petermann wrote
> > Ticker Berkin wrote
> > > I suggest replacing ANY_IN_OR_ON with SOME_OUT_NONE_IN, giving it
> > > the
> > > method string "none", like SOME_IN_NONE_OUT is referenced as
> > > "all".
> > 
> > Yes, much better. 
> 
> Thinking again about it. What would be the difference between
> is_in(..all)=true and is_in(..none)=false?
> 
> My understanding is that we want to distinguish 5 or 6 cases. Three
> methods
> returning true or false should be enough for that.
> 
> Gerd
> 
> 
> 
> --
> Sent from: 
> http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Work on is_in branch

[Ticker Berkin]

Hi Gerd

Here is a replacement for is_in-function_v10.patch with the additions:

- method ..,none)=true to replace ..,any_in_or_on)=false.

- revised documentation.

- detection of holes within the rule.polygon. Will set OUT, ie stop
'all' being true, and, if exactly ON, not set IN, ie stop 'any' being
true.

- removal the kind parameters and related logic from IsInUtil; the
IsInFunction driver has better understanding of how POLYGON processing
should differ from POLYLINE.
 
- restructure the MethodArg enum to include all the method dependent
logic.

Test case b14 (rule.polygon being the hole in the multiPolygon)
should be OUT, or maybe OUT|ON but the test driver only understands ALL
or ANY for polygons. It still fails because isLineInShape returns
IN|ON|OUT for the rule.polygon against one of the cut simple polygons,
where it should be ON|OUT

Ticker 

On Tue, 2020-02-18 at 00:23 -0700, Gerd Petermann wrote:
> Ticker Berkin wrote
> > I suggest replacing ANY_IN_OR_ON with SOME_OUT_NONE_IN, giving it
> > the
> > method string "none", like SOME_IN_NONE_OUT is referenced as "all".
> 
> Yes, much better. 
> 
> Gerd
> 
> 
> 
> 
> --
> Sent from: 
> http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-devIndex: doc/styles/rules.txt
===
--- doc/styles/rules.txt	(revision 4453)
+++ doc/styles/rules.txt	(working copy)
@@ -286,21 +286,26 @@
 +true+ if the element is in polygon(s) having the specified +tag+=+value+ according to the +method+, +false+ otherwise.
 The methods available depend on the Style section:
 
-* points:
+. polygons:
+ +all+ - all of the closed Way is within the polygon(s).
+ +any+ - some is within.
+
+. points:
  +in+ - the Node is within a polygon.
  +in_or_on+ - it is within or on the edge.
  +on+ - it is on the edge.
 
-* lines:
+. lines:
  +all+ - part of the Way is within the polygon(s), none is outside; it might touch an edge.
- +all_in_or_on+ - none is outside. This is useful for the negative - is_in(...,all_in_or_on)=false - for processing a line that is outside the polgon(s).
+ +all_in_or_on+ - none is outside.
  +on+ - it runs along the edge.
  +any+ - part is within.
- +any_in_or_on+ - part is within or in the edge.
+ +none+ - part is outside, none is inside
 
-* polygons:
- +all+ - all of the closed Way is within the polygon(s).
- +any+ - some is within.
+A common case is a line outside the polygon that runs to the edge, joining a line that is inside.
+The method to match an outside line (+none+) allows part to be on the edge,
+likewise, the method to match an inside line (+all+) allows part to be on the edge.
+The method +all_in_or_on+ additionally matches lines are only on the edge of the polygon.
 
 |
 
Index: src/uk/me/parabola/mkgmap/osmstyle/function/IsInFunction.java
===
--- src/uk/me/parabola/mkgmap/osmstyle/function/IsInFunction.java	(revision 4453)
+++ src/uk/me/parabola/mkgmap/osmstyle/function/IsInFunction.java	(working copy)
@@ -43,19 +43,33 @@
 
 	private enum MethodArg {
 
-		//   can stop when: IN ON OUT
-		POINT_IN("in",FeatureKind.POINT,true,  false, false),
-		POINT_IN_OR_ON("in_or_on",FeatureKind.POINT,true,  true,  false),
-		POINT_ON("on",FeatureKind.POINT,false, true,  false),
+		//   can stop when: IN ON OUTMERGE
+		POINT_IN("in",FeatureKind.POINT,true,  false, false, true)
+			{ @Override public boolean mapFlags(boolean hasIn, boolean hasOn, boolean hasOut) {return hasIn;} },
+		POINT_IN_OR_ON("in_or_on",FeatureKind.POINT,true,  true,  false, false)
+			{ @Override public boolean mapFlags(boolean hasIn, boolean hasOn, boolean hasOut) {return hasIn || hasOn;} },
+		POINT_ON("on",FeatureKind.POINT,false, true,  false, true)
+			{ @Override public boolean mapFlags(boolean hasIn, boolean hasOn, boolean hasOut) {return hasOn;} },
 
-		LINE_SOME_IN_NONE_OUT("all",  FeatureKind.POLYLINE, false, false, true),
-		LINE_ALL_IN_OR_ON("all_in_or_on", FeatureKind.POLYLINE, false, false, true),
-		LINE_ALL_ON("on", FeatureKind.POLYLINE, true,  false, true),
-		LINE_ANY_IN("any",FeatureKind.POLYLINE, true,  false, false),
-		LINE_ANY_IN_OR_ON("any_in_or_on", FeatureKind.POLYLINE, true,  true,  false),
+		LINE_SOME_IN_NONE_OUT("all",  FeatureKind.POLYLINE, false, false, true,  true)
+			{ @Override public 

Re: [mkgmap-dev] Work on is_in branch

[Ticker Berkin]

Hi Gerd

I don't think the test data 'expected' values are wrong, it is just
that they are more specific than the 'method' mechanism allows to be
differentiated; eg a polygon can only be tested for ALL in or ANY in.

At the moment I feel you have a reluctance about the whole concept of
the methods. Once the principle is accepted, I'll go through the test
data and add, as another tag, the list of methods that should match the
element, then change the test driver to check that these match and the
other applicable methods don't.

Reg. b14: It isn't the stop-early code that causes the problems,
isLineInShape is not giving the correct answer for a simple polygon
produced by the MP cutter.

It would be quite easy to introduce some POLYGON 'on' methods, that
match the outer, inner or either edge of a polygon, but maybe this
could wait until there is a call for it.

Next mail:
I'll change the sentence as you suggest.

Please can you commit the patch as it stands; it has a lot of good
stuff in it. Then I can do the IsInUtilTest and test data changes as
the next stage. It's also handy to see how the Style Manual looks after
each build into the download area, because I don't know how to generate
it and am just guessing at the formatting.

Thank you
Ticker

On Thu, 2020-02-20 at 15:41 +, Gerd Petermann wrote:
> Hi Ticker,
> 
> I see that you overwrite the expected value stored in the test data
> in the unit test. Please don't do this. If you think that the
> expected value in is-in-samples.osm
> is wrong we should discuss the test data.
> In my eyes b14 clearly has points on the edge (as it is part of the
> edge) and is out.
> 
> If you think the expected results are correct but your new code
> doesn't allow to test them because of the early stop code please add
> a new tag to each object or maybe create a new  file. The unit test
> file is meant to document what the code does.
> 
> Gerd
> 
> 
> Von: mkgmap-dev  im Auftrag
> von Ticker Berkin 
> Gesendet: Donnerstag, 20. Februar 2020 14:11
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Work on is_in branch
> 
> Hi Gerd
> 
> Here is a replacement for is_in-function_v10.patch with the
> additions:
> 
> - method ..,none)=true to replace ..,any_in_or_on)=false.
> 
> - revised documentation.
> 
> - detection of holes within the rule.polygon. Will set OUT, ie stop
> 'all' being true, and, if exactly ON, not set IN, ie stop 'any' being
> true.
> 
> - removal the kind parameters and related logic from IsInUtil; the
> IsInFunction driver has better understanding of how POLYGON
> processing
> should differ from POLYLINE.
> 
> - restructure the MethodArg enum to include all the method dependent
> logic.
> 
> Test case b14 (rule.polygon being the hole in the multiPolygon)
> should be OUT, or maybe OUT|ON but the test driver only understands
> ALL
> or ANY for polygons. It still fails because isLineInShape returns
> IN|ON|OUT for the rule.polygon against one of the cut simple
> polygons,
> where it should be ON|OUT
> 
> Ticker
> 
> On Tue, 2020-02-18 at 00:23 -0700, Gerd Petermann wrote:
> > Ticker Berkin wrote
> > > I suggest replacing ANY_IN_OR_ON with SOME_OUT_NONE_IN, giving it
> > > the
> > > method string "none", like SOME_IN_NONE_OUT is referenced as
> > > "all".
> > 
> > Yes, much better.
> > 
> > Gerd
> > 
> > 
> > 
> > 
> > --
> > Sent from:
> > http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html
> > ___
> > mkgmap-dev mailing list
> > mkgmap-dev@lists.mkgmap.org.uk
> > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Work on is_in branch

[Ticker Berkin]

Hi Gerd

Attached is a quick patch that cause b14 to give the correct answer for
the 'any' method and hence pass the test; merge the 2 polygons and then
it processes 1 outer, 1 hole with the expected results

When my mind is up to it, I'll try and work out what happens during the
isLineInShape processing. The hole after merging appears to retain the
same upper and lower mid-points from the cutting and matches the line,
with the values as output like (not sure what the precision is here):

line [2492250/449714, 2492167/450038, 2492073/449970, 2492155/449646,
2492250/449714]
ie the inner b14

polygon [2491978/449872, 2492086/449391, 2492384/449581,
2492319/449872, 2492209/449872, 2492250/449714, 2492155/449646,
2492097/449872, 2491978/449872]
ie 1/2 of the MP from cutting. this gives IN|ON|OUT, should be ON|OUT

hole [2492073/449970, 2492167/450038, 2492209/449872, 2492250/449714,
2492155/449646, 2492097/449872, 2492073/449970]
after the java2d merging - this gives ON

Ticker

On Thu, 2020-02-20 at 17:04 +, Gerd Petermann wrote:
> Hi Ticker,
> 
> patch is commited. It is a bit difficult for me because you change a
> lot of things and the unit test fails.
> I just want to make sure that we have something testable in the end.
> It is already difficult enough to understand what is documented.
> 
> I think the tests are not always working because the result of
> Coord.makeBetweenPoint is rounded. That means a point calculated with
> it is typically not ON the line between the given points. A possible
> solution would be to change all the code in IsInUtil to use double
> values and rewrite e.g. makeBetweenPoint and the other used methods
> to keep the double precision. Still, it might fail when java area
> code comes in because that always uses a flat earth calculation.
> When I understood that I felt indeed a bit relunctant.
> 
> Gerd
> 
> ________
> Von: mkgmap-dev  im Auftrag
> von Ticker Berkin 
> Gesendet: Donnerstag, 20. Februar 2020 17:45
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Work on is_in branch
> 
> Hi Gerd
> 
> I don't think the test data 'expected' values are wrong, it is just
> that they are more specific than the 'method' mechanism allows to be
> differentiated; eg a polygon can only be tested for ALL in or ANY in.
> 
> At the moment I feel you have a reluctance about the whole concept of
> the methods. Once the principle is accepted, I'll go through the test
> data and add, as another tag, the list of methods that should match
> the
> element, then change the test driver to check that these match and
> the
> other applicable methods don't.
> 
> Reg. b14: It isn't the stop-early code that causes the problems,
> isLineInShape is not giving the correct answer for a simple polygon
> produced by the MP cutter.
> 
> It would be quite easy to introduce some POLYGON 'on' methods, that
> match the outer, inner or either edge of a polygon, but maybe this
> could wait until there is a call for it.
> 
> Next mail:
> I'll change the sentence as you suggest.
> 
> Please can you commit the patch as it stands; it has a lot of good
> stuff in it. Then I can do the IsInUtilTest and test data changes as
> the next stage. It's also handy to see how the Style Manual looks
> after
> each build into the download area, because I don't know how to
> generate
> it and am just guessing at the formatting.
> 
> Thank you
> Ticker
Index: src/uk/me/parabola/mkgmap/osmstyle/function/IsInFunction.java
===
--- src/uk/me/parabola/mkgmap/osmstyle/function/IsInFunction.java	(revision 4455)
+++ src/uk/me/parabola/mkgmap/osmstyle/function/IsInFunction.java	(working copy)
@@ -66,7 +66,9 @@
 		
 		POLYGON_ALL("all",FeatureKind.POLYGON,  false, false, true,  true)
 			{ @Override public boolean mapFlags(boolean hasIn, boolean hasOn, boolean hasOut) {return !hasOut;} },
-		POLYGON_ANY("any",FeatureKind.POLYGON,  true,  false, false, false)
+//		POLYGON_ANY("any",FeatureKind.POLYGON,  true,  false, false, false)
+// problem with test b14 on the cut polygons and isLineInShape that goes away when merged. TODO: investigate sometime
+		POLYGON_ANY("any",FeatureKind.POLYGON,  true,  false, false, true)
 			{ @Override public boolean mapFlags(boolean hasIn, boolean hasOn, boolean hasOut) {return hasIn;} };
 
 		public abstract boolean mapFlags(boolean hasIn, boolean hasOn, boolean hasOut);
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] wrong result from is_in style function

[Ticker Berkin]

Hi Gerd

I thought of this case the other day and the fix for it is done and
will be in the next patch, which is mainly related to the test driver.

Ticker

On Mon, 2020-02-24 at 10:57 +, Gerd Petermann wrote:
> Hi Ticker,
> 
> please try attached sample file with the two rules in polygons.
> With r4456 I see 
> Way -101782 all OK
> but not 
> Way -101782 any OK
> 
> Gerd
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Work on is_in branch

[Ticker Berkin]

Hi Gerd
Patch attached that:
- rewords the sentence is the Style Manual and changes the
highlighting; I need to check the next build/download to see if this is
clearer.
- fixes polygon 'any' method to also return true if exactly ON.
- merge polygons for 'any' so that line on shared boundary is "in"
rather than "on".
- change the test driver to try all methods relevant to the element,
checking they return true/false as appropriate. I decided that, rather
than introducing a new tag saying which methods should match, it was
clearer to use the 'expected' tag value as a description of how the
element interacted with the polygons and generate the methods that
should match from this and the non-matching from a list if all methods.
Ticker
On Thu, 2020-02-20 at 16:45 +, Ticker Berkin wrote:
> Hi Gerd
> 
> I don't think the test data 'expected' values are wrong, it is just
> that they are more specific than the 'method' mechanism allows to be
> differentiated; eg a polygon can only be tested for ALL in or ANY in.
> 
> At the moment I feel you have a reluctance about the whole concept of
> the methods. Once the principle is accepted, I'll go through the test
> data and add, as another tag, the list of methods that should match
> the
> element, then change the test driver to check that these match and
> the
> other applicable methods don't.
> 
> Reg. b14: It isn't the stop-early code that causes the problems,
> isLineInShape is not giving the correct answer for a simple polygon
> produced by the MP cutter.
> 
> It would be quite easy to introduce some POLYGON 'on' methods, that
> match the outer, inner or either edge of a polygon, but maybe this
> could wait until there is a call for it.
> 
> Next mail:
> I'll change the sentence as you suggest.
> 
> Please can you commit the patch as it stands; it has a lot of good
> stuff in it. Then I can do the IsInUtilTest and test data changes as
> the next stage. It's also handy to see how the Style Manual looks
> after
> each build into the download area, because I don't know how to
> generate
> it and am just guessing at the formatting.
> 
> Thank you
> Ticker
> 
> On Thu, 2020-02-20 at 15:41 +, Gerd Petermann wrote:
> > Hi Ticker,
> > 
> > I see that you overwrite the expected value stored in the test data
> > in the unit test. Please don't do this. If you think that the
> > expected value in is-in-samples.osm
> > is wrong we should discuss the test data.
> > In my eyes b14 clearly has points on the edge (as it is part of the
> > edge) and is out.
> > 
> > If you think the expected results are correct but your new code
> > doesn't allow to test them because of the early stop code please
> > add
> > a new tag to each object or maybe create a new  file. The unit test
> > file is meant to document what the code does.
> > 
> > Gerd
Index: doc/styles/rules.txt
===
--- doc/styles/rules.txt	(revision 4456)
+++ doc/styles/rules.txt	(working copy)
@@ -283,29 +283,29 @@
 some element ids are changed and some have a faked id > 4611686018427387904.  
 
 |is_in(tag,value,method)   | x | x  |  |
-+true+ if the element is in polygon(s) having the specified +tag+=+value+ according to the +method+, +false+ otherwise.
++true+ if the element is in polygon(s) having the specified *tag=value* according to the *method*, +false+ otherwise.
 The methods available depend on the Style section:
 
-. polygons:
- +all+ - all of the closed Way is within the polygon(s).
- +any+ - some is within.
+polygons:
+ *all* - all of the closed 'way' is within the polygon(s).
+ *any* - some is within.
 
-. points:
- +in+ - the Node is within a polygon.
- +in_or_on+ - it is within or on the edge.
- +on+ - it is on the edge.
+points:
+ *in* - the 'node' is within a polygon.
+ *in_or_on* - it is within or on the edge.
+ *on* - it is on the edge.
 
-. lines:
- +all+ - part of the Way is within the polygon(s), none is outside; it might touch an edge.
- +all_in_or_on+ - none is outside.
- +on+ - it runs along the edge.
- +any+ - part is within.
- +none+ - part is outside, none is inside
+lines:
+ *all* - part of the 'way' is within the polygon(s), none is outside; it might touch an edge.
+ *all_in_or_on* - none is outside.
+ *on* - it runs along the edge.
+ *any* - part is within.
+ *none* - part is outside, none is inside.
 
 A common case is a line outside the polygon that runs to the edge, joining a line that is inside.
-The method to match an outside line (+none+) allows part to be on the edge,
-likewise, the method to match an inside line (+all+) allows part to be on the edge.
-T

Re: [mkgmap-dev] Work on is_in branch

[Ticker Berkin]

Hi Gerd

It isn't really a problem of the test driver; it is a consequence of
not having a method that distinguishes between an inner line that
touches the edge and one that doesn't, ditto for outer lines.

If there is a strong case for methods that do distinguish these cases
and they get implemented, then the new methods just needed to be added
to the allLineMethods list and expected #1 and #4 maps. Then the tests
will fail if you swap 1 & 3 or 4 & 6.

Ticker


On Mon, 2020-02-24 at 13:11 +, Gerd Petermann wrote:
> Hi Ticker,
> 
> see r4457.
> 
> I see one potential problem with your test driver:
> It does not always find a problem when the expected value in the test
> data is wrong. E.g. when I change the expected value for w2 from 1 to
> the wrong value 3 the test doesn't fail.
> 
> Gerd
> 
> ________
> Von: mkgmap-dev  im Auftrag
> von Ticker Berkin 
> Gesendet: Montag, 24. Februar 2020 13:50
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Work on is_in branch
> 
> Hi Gerd
> 
> Patch attached that:
> 
> - rewords the sentence is the Style Manual and changes the
> highlighting; I need to check the next build/download to see if this
> is clearer.
> 
> - fixes polygon 'any' method to also return true if exactly ON.
> 
> - merge polygons for 'any' so that line on shared boundary is "in"
> rather than "on".
> 
> - change the test driver to try all methods relevant to the element,
> checking they return true/false as appropriate. I decided that,
> rather than introducing a new tag saying which methods should match,
> it was clearer to use the 'expected' tag value as a description of
> how the element interacted with the polygons and generate the methods
> that should match from this and the non-matching from a list if all
> methods.
> 
> Ticker
> 
> On Thu, 2020-02-20 at 16:45 +, Ticker Berkin wrote:
> Hi Gerd
> 
> I don't think the test data 'expected' values are wrong, it is just
> that they are more specific than the 'method' mechanism allows to be
> differentiated; eg a polygon can only be tested for ALL in or ANY in.
> 
> At the moment I feel you have a reluctance about the whole concept of
> the methods. Once the principle is accepted, I'll go through the test
> data and add, as another tag, the list of methods that should match
> the
> element, then change the test driver to check that these match and
> the
> other applicable methods don't.
> 
> Reg. b14: It isn't the stop-early code that causes the problems,
> isLineInShape is not giving the correct answer for a simple polygon
> produced by the MP cutter.
> 
> It would be quite easy to introduce some POLYGON 'on' methods, that
> match the outer, inner or either edge of a polygon, but maybe this
> could wait until there is a call for it.
> 
> Next mail:
> I'll change the sentence as you suggest.
> 
> Please can you commit the patch as it stands; it has a lot of good
> stuff in it. Then I can do the IsInUtilTest and test data changes as
> the next stage. It's also handy to see how the Style Manual looks
> after
> each build into the download area, because I don't know how to
> generate
> it and am just guessing at the formatting.
> 
> Thank you
> Ticker
> 
> On Thu, 2020-02-20 at 15:41 +, Gerd Petermann wrote:
> Hi Ticker,
> 
> I see that you overwrite the expected value stored in the test data
> in the unit test. Please don't do this. If you think that the
> expected value in is-in-samples.osm
> is wrong we should discuss the test data.
> In my eyes b14 clearly has points on the edge (as it is part of the
> edge) and is out.
> 
> If you think the expected results are correct but your new code
> doesn't allow to test them because of the early stop code please add
> a new tag to each object or maybe create a new  file. The unit test
> file is meant to document what the code does.
> 
> Gerd
> 
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Work on is_in branch

[Ticker Berkin]

Hi Gerd

I think this is about ready for release.

There is a slight problem with the layout in the Style Manual in that
the width of "is_in(tag,value,method)" causes it to run into the
Node/Way/Relation flags. If there was a way to put the function args
down the first column it would fix it, but I have no idea of the rules
of the formatting language. What are the tools used to transform
doc/styles/*.txt to the style-manual.pdf? 

I'm not going to be able to do any complex line->polygon in/on/out
debugging in the next few days and it seems to work well for most
cases.

Ticker

On Mon, 2020-02-24 at 12:50 +0000, Ticker Berkin wrote:
> Hi Gerd
> 
> Patch attached that:
> 
> - rewords the sentence is the Style Manual and changes the
> highlighting; I need to check the next build/download to see if this
> is clearer.
> 
> - fixes polygon 'any' method to also return true if exactly ON.
> 
> - merge polygons for 'any' so that line on shared boundary is "in"
> rather than "on".
> 
> - change the test driver to try all methods relevant to the element,
> checking they return true/false as appropriate. I decided that,
> rather than introducing a new tag saying which methods should match,
> it was clearer to use the 'expected' tag value as a description of
> how the element interacted with the polygons and generate the methods
> that should match from this and the non-matching from a list if all
> methods.
> 
> Ticker

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Work on is_in branch

[Ticker Berkin]

Hi Gerd

Changes:

- Added comment in style-manual.txt about tools needed and how to
generate the pdf. These are asciidoc, fop, python-pygments and mkgmap
-pygments.

- Adjusted the layout of "Table 4.2. Style functions" so that
is_in(...) doesn't run into the flags and and slightly changed the
highlighting again.

- Changed log.info to log.debug.

- Added default: throw...  to a couple of switch statements. I disagree
with SonarLint that this is always good practice; here it is just
pointless clutter.

I'm not sure what the problem is with commented code blocks. I left
@override value() {...} in as commented because it clarifies what needs
to change between a CachedFunction and a StyleFunction.

doc/styles/main.txt should be deleted from svn; it has been superseded 
by style-manual.txt.

Reg. b14. It might be slight rounding errors, but the hole generated from the 
merge of the 2 halves of the outer retains the 2 cut-points and this does match 
the inner polygon, whereas, for the inner polygon, isLineInShape gives 
IN/ON/OUT against one of the halves of the outer. I'd have expected the 
problems to be the other way around.

Ticker 

On Wed, 2020-02-26 at 08:46 +, Gerd Petermann wrote:
> Hi Ticker,
> 
> no idea how the tool chain for the pdf works.
> 
> There are some commented code blocks and Eclipse and SonarLint warn
> about several missing default statements, e.g.
> Complete cases by adding the missing enum constants or add a default
> case to this switch.   IsInFunction.java  
>  mkgmap/src/uk/me/parabola/mkgmap/osmstyle/function  line 164
> SonarLint On-The-Fly Issue
> 
> Reg. the TODO comment
> // problem with test b14 on the cut polygons and isLineInShape that
> goes away when merged. TODO: investigate sometime
> Maybe the reason is that we create a Coord instance at the place
> where the polygon is split. Due to the rounding errors this point can
> be a 1-2 mm inside or outside the original inner polygon. Merging
> should not change the result unless the added point is removed by the
> merge. In that case I would assume that there were no rounding
> errors.
> 
> Some log statements might be removed or changed to debug level?
> log.info("done", System.identityHashCode(this), hasIn, hasOn,
> hasOut);
> 
> Gerd
> 
> 
> Von: mkgmap-dev  im Auftrag
> von Ticker Berkin 
> Gesendet: Dienstag, 25. Februar 2020 10:27
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Work on is_in branch
> 
> Hi Gerd
> 
> I think this is about ready for release.
> 
> There is a slight problem with the layout in the Style Manual in that
> the width of "is_in(tag,value,method)" causes it to run into the
> Node/Way/Relation flags. If there was a way to put the function args
> down the first column it would fix it, but I have no idea of the
> rules
> of the formatting language. What are the tools used to transform
> doc/styles/*.txt to the style-manual.pdf?
> 
> I'm not going to be able to do any complex line->polygon in/on/out
> debugging in the next few days and it seems to work well for most
> cases.
> 
> Ticker
> 
> On Mon, 2020-02-24 at 12:50 +, Ticker Berkin wrote:
> > Hi Gerd
> > 
> > Patch attached that:
> > 
> > - rewords the sentence is the Style Manual and changes the
> > highlighting; I need to check the next build/download to see if
> > this
> > is clearer.
> > 
> > - fixes polygon 'any' method to also return true if exactly ON.
> > 
> > - merge polygons for 'any' so that line on shared boundary is "in"
> > rather than "on".
> > 
> > - change the test driver to try all methods relevant to the
> > element,
> > checking they return true/false as appropriate. I decided that,
> > rather than introducing a new tag saying which methods should
> > match,
> > it was clearer to use the 'expected' tag value as a description of
> > how the element interacted with the polygons and generate the
> > methods
> > that should match from this and the non-matching from a list if all
> > methods.
> > 
> > Ticker
> 
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-devIndex: doc/styles/about.txt
===
--- doc/styles/about.txt	(revision 4458)
+++ doc/styles/about.txt	(working copy)
@@ -14,9 +14,9 @@
 People who have contributed suggestions and corrections to this document
 are:
 Carlos Dávila,
-Geoff Sherlock
+Geoff Sherlock,
+Ticker Berkin
 
-
 The list of nic

Re: [mkgmap-dev] Work on is_in branch

[Ticker Berkin]

Hi Gerd

Yes, I think I see where it goes in with josm at maximum zoom.

Shouldn't EPS be a bit bigger? My understanding was that a high
-precision unit was ~37mm at the equator (40,075*1000/2^24/2^6)*1000.

With your change from 10mm to 20mm all the tests pass, but wouldn't
private static final double EPS = 0.080;
be safer, to allow for 2 hp roundings away from each other.

Ticker

On Thu, 2020-02-27 at 14:42 +, Gerd Petermann wrote:
> Hi Ticker,
> 
> I've looked at b14 again. The mp-cutting produces a point which is a
> small bit inside the real hole (~1.6 mm). I've attached the gpx
> files.
> e_hp is the tested segmet of the element b14, s_hp is the tested
> segment created by cutting, shape_hp is the complete shape produced
> by the mp-cutter.
> The southern end crosses e_hp. This small overlap is ignored when the
> merged shape is analyzed. Responsible for this is the method
> isOnOrCloseToEdgeOfShape(), I think I wrote it exactly for this
> problem but it is just a work-around for the problems produced by the
> polygon cutting.
> 
> Attached is a patch which might solve the problem, didn't test it
> much. It increases the allowed distance for "ON" from 1 to 2 mm and
> handles this special case.
> 
> Gerd
> 
> 
> Von: mkgmap-dev  im Auftrag
> von Ticker Berkin 
> Gesendet: Donnerstag, 27. Februar 2020 14:01
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Work on is_in branch
> 
> Hi Gerd
> 
> Changes:
> 
> - Added comment in style-manual.txt about tools needed and how to
> generate the pdf. These are asciidoc, fop, python-pygments and mkgmap
> -pygments.
> 
> - Adjusted the layout of "Table 4.2. Style functions" so that
> is_in(...) doesn't run into the flags and and slightly changed the
> highlighting again.
> 
> - Changed log.info to log.debug.
> 
> - Added default: throw...  to a couple of switch statements. I
> disagree
> with SonarLint that this is always good practice; here it is just
> pointless clutter.
> 
> I'm not sure what the problem is with commented code blocks. I left
> @override value() {...} in as commented because it clarifies what
> needs
> to change between a CachedFunction and a StyleFunction.
> 
> doc/styles/main.txt should be deleted from svn; it has been
> superseded
> by style-manual.txt.
> 
> Reg. b14. It might be slight rounding errors, but the hole generated
> from the merge of the 2 halves of the outer retains the 2 cut-points
> and this does match the inner polygon, whereas, for the inner
> polygon, isLineInShape gives IN/ON/OUT against one of the halves of
> the outer. I'd have expected the problems to be the other way around.
> 
> Ticker
> 
> On Wed, 2020-02-26 at 08:46 +, Gerd Petermann wrote:
> > Hi Ticker,
> > 
> > no idea how the tool chain for the pdf works.
> > 
> > There are some commented code blocks and Eclipse and SonarLint warn
> > about several missing default statements, e.g.
> > Complete cases by adding the missing enum constants or add a
> > default
> > case to this switch.   IsInFunction.java
> >  mkgmap/src/uk/me/parabola/mkgmap/osmstyle/function  line 164
> > SonarLint On-The-Fly Issue
> > 
> > Reg. the TODO comment
> > // problem with test b14 on the cut polygons and isLineInShape that
> > goes away when merged. TODO: investigate sometime
> > Maybe the reason is that we create a Coord instance at the place
> > where the polygon is split. Due to the rounding errors this point
> > can
> > be a 1-2 mm inside or outside the original inner polygon. Merging
> > should not change the result unless the added point is removed by
> > the
> > merge. In that case I would assume that there were no rounding
> > errors.
> > 
> > Some log statements might be removed or changed to debug level?
> > log.info("done", System.identityHashCode(this), hasIn, hasOn,
> > hasOut);
> > 
> > Gerd
> > 
> > 
> > Von: mkgmap-dev  im Auftrag
> > von Ticker Berkin 
> > Gesendet: Dienstag, 25. Februar 2020 10:27
> > An: Development list for mkgmap
> > Betreff: Re: [mkgmap-dev] Work on is_in branch
> > 
> > Hi Gerd
> > 
> > I think this is about ready for release.
> > 
> > There is a slight problem with the layout in the Style Manual in
> > that
> > the width of "is_in(tag,value,method)" causes it to run into the
> > Node/Way/Relation flags. If there was a way to put the function
> > args
> > down the first column it would fi

Re: [mkgmap-dev] Work on is_in branch

[Ticker Berkin]

Hi Gerd

Looking at the distance calculations to compare with EPS (ie very
small), wouldn't it be much simpler and clearer just to calculate it as
highPrecisionSquared units, not bothering with degrees/radians, rhumb
-line, metre conversion etc. Then EPS would be 4.

Then, considering IsInUtil.insidePolgon and can it be changed to have
some tolerance and maybe changing the interface to return IN/ON/OUT, it
looks like it will stop, returning onBoundary, if there is a polygon
segment that 'aims at' the point.

Ticker

On Thu, 2020-02-27 at 16:42 +, Gerd Petermann wrote:
> Hi Ticker,
> 
> yes, probably the value is still too small, and I assume nobody would
> mind to use a halo of 0.08 m width.
> Small problem is that we don't use this halo with the point in shape
> tests.
> 
> Gerd
> 
> ________
> Von: mkgmap-dev  im Auftrag
> von Ticker Berkin 
> Gesendet: Donnerstag, 27. Februar 2020 17:23
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Work on is_in branch
> 
> Hi Gerd
> 
> Yes, I think I see where it goes in with josm at maximum zoom.
> 
> Shouldn't EPS be a bit bigger? My understanding was that a high
> -precision unit was ~37mm at the equator (40,075*1000/2^24/2^6)*1000.
> 
> With your change from 10mm to 20mm all the tests pass, but wouldn't
> private static final double EPS = 0.080;
> be safer, to allow for 2 hp roundings away from each other.
> 
> Ticker
> 
> On Thu, 2020-02-27 at 14:42 +, Gerd Petermann wrote:
> > Hi Ticker,
> > 
> > I've looked at b14 again. The mp-cutting produces a point which is
> > a
> > small bit inside the real hole (~1.6 mm). I've attached the gpx
> > files.
> > e_hp is the tested segmet of the element b14, s_hp is the tested
> > segment created by cutting, shape_hp is the complete shape produced
> > by the mp-cutter.
> > The southern end crosses e_hp. This small overlap is ignored when
> > the
> > merged shape is analyzed. Responsible for this is the method
> > isOnOrCloseToEdgeOfShape(), I think I wrote it exactly for this
> > problem but it is just a work-around for the problems produced by
> > the
> > polygon cutting.
> > 
> > Attached is a patch which might solve the problem, didn't test it
> > much. It increases the allowed distance for "ON" from 1 to 2 mm and
> > handles this special case.
> > 
> > Gerd
> > 
> > 
> > Von: mkgmap-dev  im Auftrag
> > von Ticker Berkin 
> > Gesendet: Donnerstag, 27. Februar 2020 14:01
> > An: Development list for mkgmap
> > Betreff: Re: [mkgmap-dev] Work on is_in branch
> > 
> > Hi Gerd
> > 
> > Changes:
> > 
> > - Added comment in style-manual.txt about tools needed and how to
> > generate the pdf. These are asciidoc, fop, python-pygments and
> > mkgmap
> > -pygments.
> > 
> > - Adjusted the layout of "Table 4.2. Style functions" so that
> > is_in(...) doesn't run into the flags and and slightly changed the
> > highlighting again.
> > 
> > - Changed log.info to log.debug.
> > 
> > - Added default: throw...  to a couple of switch statements. I
> > disagree
> > with SonarLint that this is always good practice; here it is just
> > pointless clutter.
> > 
> > I'm not sure what the problem is with commented code blocks. I left
> > @override value() {...} in as commented because it clarifies what
> > needs
> > to change between a CachedFunction and a StyleFunction.
> > 
> > doc/styles/main.txt should be deleted from svn; it has been
> > superseded
> > by style-manual.txt.
> > 
> > Reg. b14. It might be slight rounding errors, but the hole
> > generated
> > from the merge of the 2 halves of the outer retains the 2 cut
> > -points
> > and this does match the inner polygon, whereas, for the inner
> > polygon, isLineInShape gives IN/ON/OUT against one of the halves of
> > the outer. I'd have expected the problems to be the other way
> > around.
> > 
> > Ticker
> > 
> > On Wed, 2020-02-26 at 08:46 +, Gerd Petermann wrote:
> > > Hi Ticker,
> > > 
> > > no idea how the tool chain for the pdf works.
> > > 
> > > There are some commented code blocks and Eclipse and SonarLint
> > > warn
> > > about several missing default statements, e.g.
> > > Complete cases by adding the missing enum constants or add a
> > > default
> > > case to this switch.   IsInFunction.java
> 

Re: [mkgmap-dev] Tagging restaurants and categories

[Ticker Berkin]

Hi all

It relatively easy for a style to generate multiple POI for the same
point, in this case one "Fast Food" and one "Bagel/Donut".

The default style doesn't do this, but it makes a choice about which is
shown in this and similar cases, carefully commented to show how to get
the other:

# Have the following 2 lines here rather than after cuisine=... so
that, for amenity=fast_food, cuisine is ignored
amenity=fast_food & cuisine=* {add name='${cuisine|subst:"_=> "}'}
[0x2a07 resolution 24]
amenity=fast_food [0x2a07 resolution 24]

...

cuisine=bagel | cuisine=donut
[0x2a0d resolution 24]

...

Have the following 2 lines here rather than before cuisine=... so that,
for amenity=fast_food, cuisine is respected
#amenity=fast_food & cuisine=* {add name='${cuisine|subst:"_=> "}'}
[0x2a07 resolution 24]
#amenity=fast_food [0x2a07 resolution 24]

Ticker


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Work on is_in branch

[Ticker Berkin]

Hi Gerd

Patch attached:

- inherits your is_in-function_v14.patch

- adds Math.round to Coord.makeBetweenPoint(); Is this how you
indented?

- removes IsInUtil.insidePolygon() and changes callers to use
isPointInShape()

- adds ON tolerance to isPointInShape() - I couldn't work out how to do
this with the winding algo, so changed it to crossing-point, which is
fine for mkgmap polygons.

- add some more tolerances to isLineInShape

- isLineInShape had comment:

// it is unlikely but not impossible that pTest is on boundary :(

and it returned the wrong result if it was. This contributed to the
difficulties with b14 (and b19). I've fixed it and, I think, improved
and simplified the running status setting

- fix spelling of rhumLine to rhumbLine

There are still a couple of places that have complicated distance
calculation and point insertion using, bearings, rhumbline, meter
conversion but I don't think it is worth re-implementing them for this.

I'm slightly surprised how much use there is of
bearing/rhumbLine/Mercator projection calculations. I think real
distance/metre calcs should be "great circle" and internal poly/line
chopping, testing etc should be high-precision polar coords.

Ticker

On Thu, 2020-02-27 at 19:36 +, Gerd Petermann wrote:
> Hi Ticker,
> 
> if you see a way to change the algo just do it.
> I've just noticed that I forgot to commit a change  in
> Coord.makeBetweenPoint().
> This routine should use Math.round. Will reduce the error by 50%,
> right?
> 
> Gerd
> 
> ________
> Von: mkgmap-dev  im Auftrag
> von Ticker Berkin 
> Gesendet: Donnerstag, 27. Februar 2020 20:24
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Work on is_in branch
> 
> Hi Gerd
> 
> Looking at the distance calculations to compare with EPS (ie very
> small), wouldn't it be much simpler and clearer just to calculate it
> as
> highPrecisionSquared units, not bothering with degrees/radians, rhumb
> -line, metre conversion etc. Then EPS would be 4.
> 
> Then, considering IsInUtil.insidePolgon and can it be changed to have
> some tolerance and maybe changing the interface to return IN/ON/OUT,
> it
> looks like it will stop, returning onBoundary, if there is a polygon
> segment that 'aims at' the point.
> 
> Ticker
Index: src/uk/me/parabola/imgfmt/app/Coord.java
===
--- src/uk/me/parabola/imgfmt/app/Coord.java	(revision 4460)
+++ src/uk/me/parabola/imgfmt/app/Coord.java	(working copy)
@@ -56,6 +56,7 @@
 	public static final int DELTA_SHIFT = HIGH_PREC_BITS - 24; 
 	private static final int MAX_DELTA = 1 << (DELTA_SHIFT - 2); // max delta abs value that is considered okay
 	private static final long FACTOR_HP = 1L << HIGH_PREC_BITS;
+	private static final int HIGH_PREC_UNUSED_BITS = Integer.SIZE - HIGH_PREC_BITS;
 	
 	public static final double R = 6378137.0; // Radius of earth at equator as defined by WGS84
 	public static final double U = R * 2 * Math.PI; // circumference of earth at equator (WGS84)
@@ -516,6 +517,16 @@
 	}
 
 	/**
+	 * Distance to other point in high precision squared units
+	 */
+	public long distanceInHighPrecSquared(Coord other) {
+		int dLatHp = other.getHighPrecLat() - getHighPrecLat();
+		int dLonHp = other.getHighPrecLon() - getHighPrecLon();
+		dLonHp = (dLonHp << HIGH_PREC_UNUSED_BITS) >> HIGH_PREC_UNUSED_BITS; // fix wrap-around earth
+		return (long)dLatHp * dLatHp + (long)dLonHp * dLonHp;
+	}
+
+	/**
 	 * Calculate point on the line this->other. If d is the distance between this and other,
 	 * the point is {@code fraction * d} metres from this.
 	 * For small distances between this and other we use a flat earth approximation,
@@ -525,15 +536,15 @@
 	public Coord makeBetweenPoint(Coord other, double fraction) {
 		int dlatHp = other.getHighPrecLat() - getHighPrecLat();
 		int dlonHp = other.getHighPrecLon() - getHighPrecLon();
-		if (dlonHp == 0 || Math.abs(dlatHp) < 100 && Math.abs(dlonHp) < 100 ){
+		if (dlonHp == 0 || Math.abs(dlatHp) < 100 && Math.abs(dlonHp) < 100) {
 			// distances are rather small, we can use flat earth approximation
-			int latHighPrec = (int) (getHighPrecLat() + dlatHp * fraction);
-			int lonHighPrec = (int) (getHighPrecLon() + dlonHp * fraction);
+			int latHighPrec = (int)Math.round(getHighPrecLat() + dlatHp * fraction);
+			int lonHighPrec = (int)Math.round(getHighPrecLon() + dlonHp * fraction);
 			return makeHighPrecCoord(latHighPrec, lonHighPrec);
 		}
 		double brng = this.bearingToOnRhumbLine(other, true);
 		double dist = this.distance(other) * fraction;
-		return this.destOnRhumLine(dist, brng);
+		return this.destOnRhumbLine(dist, brng);
 	}
 
 	
@@ -763,7 +774,7 @@
 	 * @param brng bearing in degrees
 	 * @return a

[mkgmap-dev] options.txt tidy-up

[Ticker Berkin]

Hi Gerd

I've had some tidy-ups to doc/options.txt sitting around for a couple
of weeks and just got merge problems with the latest changes, so I've
merged manually and attach patch.

Changes are mostly adding some missing blank lines between options and
removing some excess ones. Also fix a line folding problem that show on
the web-site and remove trailing spaces.

Ticker
Index: doc/options.txt
===
--- doc/options.txt	(revision 4462)
+++ doc/options.txt	(working copy)
@@ -19,9 +19,10 @@
 need to use this option to allow more memory to be allocated to the Java
 heap. Typically, mkgmap requires about 500MB per core, so an 8-core
 processor might need to specify -Xmx4g - note there is no space or
-equals sign in the option.  
+equals sign in the option.
 
 ;-enableassertions
+;-ea
 :	Causes an error to be thrown if an assertion written in the mkgmap
 code is evaluated as not true. This is useful in detecting bugs in the
 mkgmap code.
@@ -35,7 +36,7 @@
 === Mkgmap options ===
 
 The order of the options is significant in that options only apply
-to subsequent input files. If you are using splitter, you probably 
+to subsequent input files. If you are using splitter, you probably
 will need to put most of your options before '-c template.args'
 (this file is generated by splitter).
 
@@ -47,7 +48,7 @@
 : 	Display help on the given topic. If the topic is omitted then
 general help information is displayed, the same as in help=help.
 
-;--version 
+;--version
 : 	Write program version to stderr.
 
 === File options ===
@@ -55,7 +56,7 @@
 ;filename
 ;--input-file=filename
 : 	Read input data from the given file.  This option (or just a
-filename) may be specified more than once. Make sure you set all 
+filename) may be specified more than once. Make sure you set all
 wanted options before this.
 
 ;--gmapsupp
@@ -80,7 +81,7 @@
 Lines beginning with a # character are ignored and can be used as
 comments.  Any command line option can be specified, however the
 leading '--' must be omitted.  The short option names with a single
-'-' cannot be used, simply use the long name instead. 
+'-' cannot be used, simply use the long name instead.
 
 ;--output-dir=directory
 :	Specify the directory in which all output files are written. It defaults
@@ -144,7 +145,7 @@
 gmapsupp.img file so that address search will work on a GPS
 device.
 
-If both the --gmapsupp and any of --tdbfile, --gmapi, or --nsis options 
+If both the --gmapsupp and any of --tdbfile, --gmapi, or --nsis options
 are given alongside the --index option, then both indexes will be created.
 Note that this will require roughly twice as much memory.
 
@@ -188,17 +189,17 @@
 of special characters in the road labels to mark the beginning and end of
 the important part. In combination with option --split-name-index
 only the words in the important part are indexed.
-
+
 :There are two main effects of this option:
 ::	- On the PC, when zooming out, the name 'Rue de la Concorde' is only
 rendered as 'Concorde'.
 ::	- The index for road names only contains the important part of the name.
 You can search for road name Conc to find road names like 'Rue de la Concorde'.
-However, a search for 'Rue' will not list 'Rue de la Concorde' or
-'Rue du Moulin'. It may list 'Rueben Brookins Road' if that is in the map.
+However, a search for 'Rue' will not list 'Rue de la Concorde' or 'Rue du Moulin'.
+It may list 'Rueben Brookins Road' if that is in the map.
 Only MapSource shows a corresponding hint.
-
-::	Another effect is that the index is smaller. 
+
+::	Another effect is that the index is smaller.
 :	See comments in the sample roadNameConfig.txt for further details.
 
 ;--mdr7-excl=name[,name...]
@@ -221,8 +222,8 @@
 ::	- 0x00 .. 0x0f (cities, sub type 0, type <= 0xf)
 ::	- 0x2axx..0x30xx (Food & Drink, Lodging, ...)
 ::	- 0x28xx (no category ?)
-::	- 0x64xx .. 0x66xx (attractions)   
-:	This option allows the exclusion of POI types from the index. 
+::	- 0x64xx .. 0x66xx (attractions)
+:	This option allows the exclusion of POI types from the index.
 The excluded types are not indexed, but may still be searchable on a device,
 as some devices seem to ignore most of the index, e.g. an Oregon 600 with
 firmware 5.00 only seems to use it for city search.
@@ -229,13 +230,13 @@
 If your device finds a POI name like 'Planet' when you search for 'Net',
 it doesn't use the index because the index created by mkgmap cannot help for
 that search.
-
+
 :	So, this option may help when you care about the size of the index or the
-memory that is needed to calculate it.
+memory that is needed to calculate it.
 The option expects a comma separated list of types or type ranges. A range is
 given with from-type-to-type, e.g. 0x6400-0x6405. First and last type are both
-excluded.  A range can span multiple types, e.g. 0x6400-0x661f.  
-:	Examples for usage: 
+excluded.  A range can span multiple types, e.g. 0x6400-0x661f.
+:	

Re: [mkgmap-dev] is_in example?

[Ticker Berkin]

Hi Nick

It hasn't been merged into the main trunk yet. You need to download the
latest Branch build: mkgmap-is-in-r.zip

Ticker

On Thu, 2020-03-05 at 11:03 -0700, nwillink wrote:
> Hi
> 
> Can anyone tell me how to use the revised is_in function as I'm just
> getting
> the following errors.
> 
> 
> 
> Error in style: Error: (points:521): Expecting ) instead saw landuse
> 
> I can't seem to find any practical  examples :(
> 
> 
> With an older version this works:
> 
> barrier=gate &  is_in(landuse,residential,all)=true  {delete barrier}
> 
> I tried 
> 
> barrier=gate &  is_in(landuse,residential,in_or_on)=true  {delete
> barrier}
> 
> But again , I get the same error.
> 
> Perhaps , the function still hush-hush ;)
> 
> Regards
> 
> Nick
> 
> 
> 
> 
> --
> Sent from: 
> http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] options.txt tidy-up

[Ticker Berkin]

Hi Mike

It looks like buildOptions, except for , trims trailing spaces and
folds lines sensibly. For , the less it does the better, so I
don't think it should be changed.

The trailing spaces don't show on the web-site because of standard html
processing, but they are output to the page. I deleted them on
principle!

The web-site processing does have a problem with lines that start with
a '; it doesn't put in a separating space. I've just noticed 1 that I m
issed.

Ticker

On Thu, 2020-03-05 at 17:41 +, Mike Baggaley wrote:
> HI Ticker, I see that the options file has a few spaces on the end of
> lines that you have also corrected. These probably need a tweak to
> the buildoptions code to prevent them from being copied from
> options.txt. They seem to be occurring on blank lines and lines
> contained within  .
> 
> Regards,
> Mike
> 
> -Original Message-
> From: Ticker Berkin [mailto:rwb-mkg...@jagit.co.uk] 
> Sent: 05 March 2020 12:15
> To: mkgmap development 
> Subject: [mkgmap-dev] options.txt tidy-up
> 
> Hi Gerd
> 
> I've had some tidy-ups to doc/options.txt sitting around for a couple
> of weeks and just got merge problems with the latest changes, so I've
> merged manually and attach patch.
> 
> Changes are mostly adding some missing blank lines between options
> and
> removing some excess ones. Also fix a line folding problem that show
> on
> the web-site and remove trailing spaces.
> 
> Ticker
> 
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] options.txt tidy-up

[Ticker Berkin]

Yes

Here it is

Ticker

On Fri, 2020-03-06 at 08:15 +, Gerd Petermann wrote:
> Hi Ticker,
> 
> so I wait for another patch, right?
> 
> Gerd
> 
> 
> Von: mkgmap-dev  im Auftrag
> von Ticker Berkin 
> Gesendet: Donnerstag, 5. März 2020 19:38
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] options.txt tidy-up
> 
> Hi Mike
> 
> It looks like buildOptions, except for , trims trailing spaces
> and
> folds lines sensibly. For , the less it does the better, so I
> don't think it should be changed.
> 
> The trailing spaces don't show on the web-site because of standard
> html
> processing, but they are output to the page. I deleted them on
> principle!
> 
> The web-site processing does have a problem with lines that start
> with
> a '; it doesn't put in a separating space. I've just noticed 1 that I
> m
> issed.
> 
> Ticker
> 
> On Thu, 2020-03-05 at 17:41 +, Mike Baggaley wrote:
> > HI Ticker, I see that the options file has a few spaces on the end
> > of
> > lines that you have also corrected. These probably need a tweak to
> > the buildoptions code to prevent them from being copied from
> > options.txt. They seem to be occurring on blank lines and lines
> > contained within  .
> > 
> > Regards,
> > Mike
> > 
> > -Original Message-
> > From: Ticker Berkin [mailto:rwb-mkg...@jagit.co.uk]
> > Sent: 05 March 2020 12:15
> > To: mkgmap development 
> > Subject: [mkgmap-dev] options.txt tidy-up
> > 
> > Hi Gerd
> > 
> > I've had some tidy-ups to doc/options.txt sitting around for a
> > couple
> > of weeks and just got merge problems with the latest changes, so
> > I've
> > merged manually and attach patch.
> > 
> > Changes are mostly adding some missing blank lines between options
> > and
> > removing some excess ones. Also fix a line folding problem that
> > show
> > on
> > the web-site and remove trailing spaces.
> > 
> > Ticker
> > 
> > ___
> > mkgmap-dev mailing list
> > mkgmap-dev@lists.mkgmap.org.uk
> > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-devIndex: doc/options.txt
===
--- doc/options.txt	(revision 4462)
+++ doc/options.txt	(working copy)
@@ -19,9 +19,10 @@
 need to use this option to allow more memory to be allocated to the Java
 heap. Typically, mkgmap requires about 500MB per core, so an 8-core
 processor might need to specify -Xmx4g - note there is no space or
-equals sign in the option.  
+equals sign in the option.
 
 ;-enableassertions
+;-ea
 :	Causes an error to be thrown if an assertion written in the mkgmap
 code is evaluated as not true. This is useful in detecting bugs in the
 mkgmap code.
@@ -35,7 +36,7 @@
 === Mkgmap options ===
 
 The order of the options is significant in that options only apply
-to subsequent input files. If you are using splitter, you probably 
+to subsequent input files. If you are using splitter, you probably
 will need to put most of your options before '-c template.args'
 (this file is generated by splitter).
 
@@ -47,7 +48,7 @@
 : 	Display help on the given topic. If the topic is omitted then
 general help information is displayed, the same as in help=help.
 
-;--version 
+;--version
 : 	Write program version to stderr.
 
 === File options ===
@@ -55,7 +56,7 @@
 ;filename
 ;--input-file=filename
 : 	Read input data from the given file.  This option (or just a
-filename) may be specified more than once. Make sure you set all 
+filename) may be specified more than once. Make sure you set all
 wanted options before this.
 
 ;--gmapsupp
@@ -79,8 +80,8 @@
 
 Lines beginning with a # character are ignored and can be used as
 comments.  Any command line option can be specified, however the
-leading '--' must be omitted.  The short option names with a single
-'-' cannot be used, simply use the long name instead. 
+leading '--' must be omitted.
+The short option names with a single '-' cannot be used, simply use the long name instead.
 
 ;--output-dir=directory
 :	Specify the directory in which all output files are written. It defaults
@@ -144,7 +145,7 @@
 gmapsupp.img file so that address search will work on a GPS
 device.
 
-If both the --gmapsupp and any of --tdbfile, --gmapi, or --nsis options 
+If both the --gmapsupp and any of --tdbfile, --gmapi, or --nsis options
 are given alongside the --index option, then b

Re: [mkgmap-dev] Work on is_in branch

[Ticker Berkin]

Hi Gerd

Nothing else I want to change. I keep thinking there must be other ways
to do the lineInShape logic, but I think it has taken enough time
already.

Ticker

On Fri, 2020-03-06 at 08:16 +, Gerd Petermann wrote:
> Hi Ticker,
> 
> My concerns regarding a merge to trunk are resolved. Anything else
> you want to change?
> 
> Gerd
> 
> 
> 
> Von: mkgmap-dev  im Auftrag
> von Gerd Petermann 
> Gesendet: Dienstag, 3. März 2020 15:22
> An: Ticker Berkin; Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Work on is_in branch
> 
> Hi Ticker,
> 
> nice :)
> Committed with r4461, with small changes.
> 
> This even allows to change the test case for lamp4 from expected="?"
> to expected="2" (ON).
> 
> reg. the distance calculations: I don't remember the details and
> maybe all is wrong.
> 
> See svn log for r : 
> http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=
> and search the archives for "Great Britain National Grid".
> 
> The math behind projections and distance formulas is too complex for
> me.
> 
> Gerd
> 
> 
> Von: mkgmap-dev  im Auftrag
> von Ticker Berkin 
> Gesendet: Dienstag, 3. März 2020 14:24
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Work on is_in branch
> 
> Hi Gerd
> 
> Patch attached:
> 
> - inherits your is_in-function_v14.patch
> 
> - adds Math.round to Coord.makeBetweenPoint(); Is this how you
> indented?
> 
> - removes IsInUtil.insidePolygon() and changes callers to use
> isPointInShape()
> 
> - adds ON tolerance to isPointInShape() - I couldn't work out how to
> do
> this with the winding algo, so changed it to crossing-point, which is
> fine for mkgmap polygons.
> 
> - add some more tolerances to isLineInShape
> 
> - isLineInShape had comment:
> 
> // it is unlikely but not impossible that pTest is on boundary :(
> 
> and it returned the wrong result if it was. This contributed to the
> difficulties with b14 (and b19). I've fixed it and, I think, improved
> and simplified the running status setting
> 
> - fix spelling of rhumLine to rhumbLine
> 
> There are still a couple of places that have complicated distance
> calculation and point insertion using, bearings, rhumbline, meter
> conversion but I don't think it is worth re-implementing them for
> this.
> 
> I'm slightly surprised how much use there is of
> bearing/rhumbLine/Mercator projection calculations. I think real
> distance/metre calcs should be "great circle" and internal poly/line
> chopping, testing etc should be high-precision polar coords.
> 
> Ticker
> 
> On Thu, 2020-02-27 at 19:36 +, Gerd Petermann wrote:
> > Hi Ticker,
> > 
> > if you see a way to change the algo just do it.
> > I've just noticed that I forgot to commit a change  in
> > Coord.makeBetweenPoint().
> > This routine should use Math.round. Will reduce the error by 50%,
> > right?
> > 
> > Gerd
> > 
> > 
> > Von: mkgmap-dev  im Auftrag
> > von Ticker Berkin 
> > Gesendet: Donnerstag, 27. Februar 2020 20:24
> > An: Development list for mkgmap
> > Betreff: Re: [mkgmap-dev] Work on is_in branch
> > 
> > Hi Gerd
> > 
> > Looking at the distance calculations to compare with EPS (ie very
> > small), wouldn't it be much simpler and clearer just to calculate
> > it
> > as
> > highPrecisionSquared units, not bothering with degrees/radians,
> > rhumb
> > -line, metre conversion etc. Then EPS would be 4.
> > 
> > Then, considering IsInUtil.insidePolgon and can it be changed to
> > have
> > some tolerance and maybe changing the interface to return
> > IN/ON/OUT,
> > it
> > looks like it will stop, returning onBoundary, if there is a
> > polygon
> > segment that 'aims at' the point.
> > 
> > Ticker
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] options.txt tidy-up

[Ticker Berkin]

Sorry - corrected patch attached

Ticker

On Fri, 2020-03-06 at 09:33 +, Gerd Petermann wrote:
> Hi Ticker,
> 
> please check, options_v2.patch changes several other files.
> 
> Gerd
> 
> 
> Von: mkgmap-dev  im Auftrag
> von Ticker Berkin 
> Gesendet: Freitag, 6. März 2020 10:30
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] options.txt tidy-up
> 
> Yes
> 
> Here it is
> 
> Ticker
> 
> On Fri, 2020-03-06 at 08:15 +, Gerd Petermann wrote:
> > Hi Ticker,
> > 
> > so I wait for another patch, right?
> > 
> > Gerd
> > 
> > 
> > Von: mkgmap-dev  im Auftrag
> > von Ticker Berkin 
> > Gesendet: Donnerstag, 5. März 2020 19:38
> > An: Development list for mkgmap
> > Betreff: Re: [mkgmap-dev] options.txt tidy-up
> > 
> > Hi Mike
> > 
> > It looks like buildOptions, except for , trims trailing spaces
> > and
> > folds lines sensibly. For , the less it does the better, so I
> > don't think it should be changed.
> > 
> > The trailing spaces don't show on the web-site because of standard
> > html
> > processing, but they are output to the page. I deleted them on
> > principle!
> > 
> > The web-site processing does have a problem with lines that start
> > with
> > a '; it doesn't put in a separating space. I've just noticed 1 that
> > I
> > m
> > issed.
> > 
> > Ticker
> > 
> > On Thu, 2020-03-05 at 17:41 +, Mike Baggaley wrote:
> > > HI Ticker, I see that the options file has a few spaces on the
> > > end
> > > of
> > > lines that you have also corrected. These probably need a tweak
> > > to
> > > the buildoptions code to prevent them from being copied from
> > > options.txt. They seem to be occurring on blank lines and lines
> > > contained within  .
> > > 
> > > Regards,
> > > Mike
> > > 
> > > -Original Message-
> > > From: Ticker Berkin [mailto:rwb-mkg...@jagit.co.uk]
> > > Sent: 05 March 2020 12:15
> > > To: mkgmap development 
> > > Subject: [mkgmap-dev] options.txt tidy-up
> > > 
> > > Hi Gerd
> > > 
> > > I've had some tidy-ups to doc/options.txt sitting around for a
> > > couple
> > > of weeks and just got merge problems with the latest changes, so
> > > I've
> > > merged manually and attach patch.
> > > 
> > > Changes are mostly adding some missing blank lines between
> > > options
> > > and
> > > removing some excess ones. Also fix a line folding problem that
> > > show
> > > on
> > > the web-site and remove trailing spaces.
> > > 
> > > Ticker
> > > 
> > > ___
> > > mkgmap-dev mailing list
> > > mkgmap-dev@lists.mkgmap.org.uk
> > > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> > ___
> > mkgmap-dev mailing list
> > mkgmap-dev@lists.mkgmap.org.uk
> > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-devIndex: doc/options.txt
===
--- doc/options.txt	(revision 4462)
+++ doc/options.txt	(working copy)
@@ -19,9 +19,10 @@
 need to use this option to allow more memory to be allocated to the Java
 heap. Typically, mkgmap requires about 500MB per core, so an 8-core
 processor might need to specify -Xmx4g - note there is no space or
-equals sign in the option.  
+equals sign in the option.
 
 ;-enableassertions
+;-ea
 :	Causes an error to be thrown if an assertion written in the mkgmap
 code is evaluated as not true. This is useful in detecting bugs in the
 mkgmap code.
@@ -35,7 +36,7 @@
 === Mkgmap options ===
 
 The order of the options is significant in that options only apply
-to subsequent input files. If you are using splitter, you probably 
+to subsequent input files. If you are using splitter, you probably
 will need to put most of your options before '-c template.args'
 (this file is generated by splitter).
 
@@ -47,7 +48,7 @@
 : 	Display help on the given topic. If the topic is omitted then
 general help information is displayed, the same as in help=help.
 
-;--version 
+;--version
 : 	Write program version to stderr.
 
 === File options ===
@@ -55,7 +56,7 @@
 ;filename
 ;--input-file=filename
 : 	Read input data from the given file.  This option (or just a
-filename) may be specified more than once. Make sure you set all 
+filename) may be specified mo

Re: [mkgmap-dev] precompiled sea

[Ticker Berkin]

Hi Gerd, Mike

Considering --generate-sea=... and SeaGenerator.java.

Following changes around r4381, many more tiles have land/sea flipped,
and, looking at the log files, MultiPolygonRelation gives errors for
the sea relation, complaining about inner polygons being in inner
polygons etc.

The code relating to extracting polygons from the coastline doesn't
seem to understand what it is doing regarding the change in behaviour
between land polygons on a sea tile and vice-versa and I have little
confidence in its ability to handle complex coastlines.

So, I've re-written the guts of it to fix these shortcomings. I haven't
touched the "floodblocker" code, which I think should be
decommissioned.

Patch attached. There are a few other aspects that to this code that I
think could be improved.

Ticker

On Thu, 2020-01-30 at 11:35 +, Ticker Berkin wrote:
> 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.
> 
> It's not a problem for me at the moment, I've simply replaced above
> with
>   --precomp-sea=sea-latest.zip
> 
> However I prefer to use --generate-sea for various reasons:
> - saves downloading sea.zip every now and again.
> - island cut-outs match land features exactly, whereas there were
> slight differences with sea.zip.
> - not had these problems before.
> - no noticeable performance problems.
> 
> Sometime I'll try and pin down when the change happened. I hadn't
> noticed before because the tiles in the small map I use day-to-day
> don't show the problem.
> 
> Ticker
> 
> On Wed, 2020-01-29 at 22:50 +, Mike Baggaley wrote:
> > Hi Gerd, up to now I have built my UK map with the sea and land in
> > a
> > single
> > pass using --generate-sea. However, some tiles are getting the sea
> > and land
> > inverted, typically where a very small amount of sea is in the
> > tile.
> > I was
> > trying to see whether if I precompiled the sea, the problem would
> > go
> > away -
> > I was assuming the tiles of precompiled sea would be bigger because
> > they
> > contained no other data, so the probability of inversion would be
> > reduced. I
> > was therefore first trying to generate precompiled sea, then use it
> > to build
> > my UK map. It may be that my assumption is incorrect and that it
> > won't make
> > any difference anyway.
> > 
> > Regards,
> > Mike
Index: src/uk/me/parabola/mkgmap/reader/osm/SeaGenerator.java
===
--- src/uk/me/parabola/mkgmap/reader/osm/SeaGenerator.java	(revision 4468)
+++ src/uk/me/parabola/mkgmap/reader/osm/SeaGenerator.java	(working copy)
@@ -75,6 +75,9 @@
 	private ElementSaver saver;
 
 	private List shoreline = new ArrayList<>();
+	private	List islands = new ArrayList<>();
+	private	List antiIslands = new ArrayList<>();
+	private Area tileBounds;
 	private boolean generateSeaBackground = true;
 
 	private String[] coastlineFilenames;
@@ -426,6 +429,19 @@
 		if (precompSea != null)
 			splitCoastLineToLineAndShape(way, natural);
 		else if (coastlineFilenames == null) {
+			/* RWB ???
+			 *
+			 * I'd have thought it better to leave the original way, which has been saved,
+			 * untouched. The copy doesn't need any tags at this point. Later it might
+			 * be made into a polygon and tagged as land or sea.
+			 *
+			 * Could do a couple of quick check here to save effort later:
+			 * 1/ if no part in tile then stop, don't change anything or save.
+			 * 2/ if closed(), add to island list instead of shoreline. Any single closed
+			 *way will be a small island, not a sea! Later, after shoreline
+			 *has been merged/clipped etc, check these again for clipping and add clippings
+			 *to shoreline and unclipped back into islands
+			 */
 			// create copy of way that has only the natural=coastline tag
 			Way shore = new Way(way.getOriginalId(), way.getPoints());
 			shore.setFakeId();
@@ -583,7 +599,7 @@
 		} else {
 			// using polygons
 			// first add the complete bounding box as sea
-			saver.addWay(createSeaWay(saver.getBoundingBox(), false));
+			saver.addWay(createSeaWay(false));
 		}
 		
 		// check if the land tags need to be changed
@@ -793,6 +809,7 @@
 	 */
 	@Override
 	public void end() {
+		tileBounds = saver.getBoundingBox();
 		// precompiled sea has highest priority
 		// if it is set do not perform any other algorithm
 		if (precompSea != null && precompIndex.get() != null) {
@@ -800,7 +817,6 @@
 			retur

Re: [mkgmap-dev] precompiled sea

[Ticker Berkin]

Hi Gerd

I was just going through the code and this is what I had so far:

The significant changes are in createInnerWays/createLandPolygons

r4389 createInnerWays extracts land/anticlockwise/islands from the
hitMap. It has some logical mistakes like a 50% chance of putting an
erroneous start/end point on an earlier edge from where the real land
is cut by the tile bounds; this is like a spike, but possibly going
round 3 corners and back!

Then, unless the only shoreline is an enclosed sea
(Caspian/Black/Dead/...?) or there are sea-sectors, it will generated a
sea background and MP.cutout all the land.

Otherwise it generates a land background with this as the MP relation
inner but probably no outers unless there are sea-sectors.

r4392 has similar behaviour and I was just getting to the bit that
you've found where addCorners needed fixing.

My version simplifies and fixes createLandPolygons and addCorners.

It also has other improvements:

If the tile doesn't have any real islands, make it land based and have
any encroaching sea as sea polygons.

If using option sea-sectors: 
- Put the triangles on the correct side of the coastline rather than
the 50% chance it had before.
- Don't force the background to land as an "inner" of the triangles
"outer"
- rather, if tile is land, show sea-triangle on the sea-side, if the
background is sea, show a land-triangle on the land-side.

There are a few other minor fixes and tidy-ups

Ticker 

On Wed, 2020-03-18 at 10:05 +, Gerd Petermann wrote:
> Hi Ticker,
> 
> OK, my results:
> The refactoring in r4382 introduced two bugs.
> With the partial revert in r4391 both bugs were fixed.
> With r4392 one bug was re-introduced.  :(
> I've attached a small patch for that.
> 
> Now I wonder if your longer patch fixes any other issues?
> 
> Gerd

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] precompiled sea

[Ticker Berkin]

Hi Gerd

The version in my patch is simpler and works for both
createLandPolygons and createSeaPolygons (both contain a subtle "+= 4")

Ticker 

On Wed, 2020-03-18 at 10:26 +, Gerd Petermann wrote:
> Hi Ticker,
> 
> I finally understood what was wrong in the addCorners() method, so
> this patch shows the minimal change to make it work.
> 
> Gerd

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] Performance with --bounds option

[Ticker Berkin]

Hi Gerd

With the current version I have a tile that takes 3.5 hours to build.
With an old version (r4295) it took about 3 minutes. Without --bounds
it takes 1 minute 15 secs.

Relevant options are:
 --bounds=bounds.zip --location-autofill=is_in,nearest


>From the mkgmap.log files:
INFO: uk.me.parabola.mkgmap.reader.osm.LocationHook 
 ../mapGB/74220001.osm.pbf: Checking bounds dir took 66 ms
...
INFO: uk.me.parabola.mkgmap.reader.osm.LocationHook 
 ../mapGB/74220001.osm.pbf: Starting with location hook
INFO: uk.me.parabola.mkgmap.reader.osm.boundary.BoundaryUtil 
 ../mapGB/74220001.osm.pbf: loading boundary file: bounds_265_
-75.bnd
... about 40 similar messages ...
INFO: uk.me.parabola.mkgmap.reader.osm.boundary.BoundaryUtil 
 ../mapGB/74220001.osm.pbf: loading boundary file: bounds_280_
-25.bnd
WARN: uk.me.parabola.mkgmap.reader.osm.boundary.BoundaryGrid 
 ../mapGB/74220001.osm.pbf: no precompiled boundary information
available for raster tile 275_-40
... 16 similar messages ...
WARN: uk.me.parabola.mkgmap.reader.osm.boundary.BoundaryGrid 
 ../mapGB/74220001.osm.pbf: no precompiled boundary information
available for raster tile 280_-25
INFO: uk.me.parabola.mkgmap.reader.osm.LocationHook 
 ../mapGB/74220001.osm.pbf: === LocationHook Stats =
INFO: uk.me.parabola.mkgmap.reader.osm.LocationHook 
 ../mapGB/74220001.osm.pbf: QuadTree searches: 97834
INFO: uk.me.parabola.mkgmap.reader.osm.LocationHook 
 ../mapGB/74220001.osm.pbf: unsuccesfull : 20
INFO: uk.me.parabola.mkgmap.reader.osm.LocationHook 
 ../mapGB/74220001.osm.pbf: unsuccesfull for ways: 9
INFO: uk.me.parabola.mkgmap.reader.osm.LocationHook 
 ../mapGB/74220001.osm.pbf: Location hook finished in 12747318 ms

The old version had similar lines, but the stats at the end are:

INFO: uk.me.parabola.mkgmap.reader.osm.LocationHook 
 ../mapGB/74220001.osm.pbf: === LocationHook Stats =
INFO: uk.me.parabola.mkgmap.reader.osm.LocationHook 
 ../mapGB/74220001.osm.pbf: QuadTree searches: 95639
INFO: uk.me.parabola.mkgmap.reader.osm.LocationHook 
 ../mapGB/74220001.osm.pbf: unsuccesfull : 20
INFO: uk.me.parabola.mkgmap.reader.osm.LocationHook 
 ../mapGB/74220001.osm.pbf: unsuccesfull for ways: 9
INFO: uk.me.parabola.mkgmap.reader.osm.LocationHook 
 ../mapGB/74220001.osm.pbf: Location hook finished in 113704 ms

Ticker

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Performance with --bounds option

[Ticker Berkin]

Hi Gerd

It's

74220001: 2674688,-700416 to 2811904,-233472
#   : 57.392578,-15.029297 to 60.336914,-5.009766

Ticker

On Wed, 2020-03-18 at 10:46 +, Gerd Petermann wrote:
> Hi Ticker,
> 
> please tell me the tile boundaries
> 
> Gerd
> 
> 
> 
> Von: mkgmap-dev  im Auftrag
> von Ticker Berkin 
> Gesendet: Mittwoch, 18. März 2020 11:43
> An: mkgmap development
> Betreff: [mkgmap-dev] Performance with --bounds option
> 
> Hi Gerd
> 
> With the current version I have a tile that takes 3.5 hours to build.
> With an old version (r4295) it took about 3 minutes. Without --bounds
> it takes 1 minute 15 secs.
> 
> Relevant options are:
>  --bounds=bounds.zip --location-autofill=is_in,nearest
> 
> 
> From the mkgmap.log files:
> INFO: uk.me.parabola.mkgmap.reader.osm.LocationHook
>  ../mapGB/74220001.osm.pbf: Checking bounds dir took 66 ms
> ...
> INFO: uk.me.parabola.mkgmap.reader.osm.LocationHook
>  ../mapGB/74220001.osm.pbf: Starting with location hook
> INFO: uk.me.parabola.mkgmap.reader.osm.boundary.BoundaryUtil
>  ../mapGB/74220001.osm.pbf: loading boundary file: bounds_265_
> -75.bnd
> ... about 40 similar messages ...
> INFO: uk.me.parabola.mkgmap.reader.osm.boundary.BoundaryUtil
>  ../mapGB/74220001.osm.pbf: loading boundary file: bounds_280_
> -25.bnd
> WARN: uk.me.parabola.mkgmap.reader.osm.boundary.BoundaryGrid
>  ../mapGB/74220001.osm.pbf: no precompiled boundary information
> available for raster tile 275_-40
> ... 16 similar messages ...
> WARN: uk.me.parabola.mkgmap.reader.osm.boundary.BoundaryGrid
>  ../mapGB/74220001.osm.pbf: no precompiled boundary information
> available for raster tile 280_-25
> INFO: uk.me.parabola.mkgmap.reader.osm.LocationHook
>  ../mapGB/74220001.osm.pbf: === LocationHook Stats =
> INFO: uk.me.parabola.mkgmap.reader.osm.LocationHook
>  ../mapGB/74220001.osm.pbf: QuadTree searches: 97834
> INFO: uk.me.parabola.mkgmap.reader.osm.LocationHook
>  ../mapGB/74220001.osm.pbf: unsuccesfull : 20
> INFO: uk.me.parabola.mkgmap.reader.osm.LocationHook
>  ../mapGB/74220001.osm.pbf: unsuccesfull for ways: 9
> INFO: uk.me.parabola.mkgmap.reader.osm.LocationHook
>  ../mapGB/74220001.osm.pbf: Location hook finished in 12747318 ms
> 
> The old version had similar lines, but the stats at the end are:
> 
> INFO: uk.me.parabola.mkgmap.reader.osm.LocationHook
>  ../mapGB/74220001.osm.pbf: === LocationHook Stats =
> INFO: uk.me.parabola.mkgmap.reader.osm.LocationHook
>  ../mapGB/74220001.osm.pbf: QuadTree searches: 95639
> INFO: uk.me.parabola.mkgmap.reader.osm.LocationHook
>  ../mapGB/74220001.osm.pbf: unsuccesfull : 20
> INFO: uk.me.parabola.mkgmap.reader.osm.LocationHook
>  ../mapGB/74220001.osm.pbf: unsuccesfull for ways: 9
> INFO: uk.me.parabola.mkgmap.reader.osm.LocationHook
>  ../mapGB/74220001.osm.pbf: Location hook finished in 113704 ms
> 
> Ticker
> 
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Performance with --bounds option

[Ticker Berkin]

Have done:

http://files.mkgmap.org.uk/download/462/74220001.osm.pbf

Ticker

On Wed, 2020-03-18 at 16:26 +, Gerd Petermann wrote:
> Hi Ticker,
> 
> will look at it tomorrow. Maybe you can upload the file to 
> http://files.mkgmap.org.uk/
> 
> Gerd
> 
> 
> Von: mkgmap-dev  im Auftrag
> von Ticker Berkin 
> Gesendet: Mittwoch, 18. März 2020 11:56
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Performance with --bounds option
> 
> Hi Gerd
> 
> It's
> 
> 74220001: 2674688,-700416 to 2811904,-233472
> #   : 57.392578,-15.029297 to 60.336914,-5.009766
> 
> Ticker
> 
> On Wed, 2020-03-18 at 10:46 +, Gerd Petermann wrote:
> > Hi Ticker,
> > 
> > please tell me the tile boundaries
> > 
> > Gerd
> > 
> > 
> > 
> > Von: mkgmap-dev  im Auftrag
> > von Ticker Berkin 
> > Gesendet: Mittwoch, 18. März 2020 11:43
> > An: mkgmap development
> > Betreff: [mkgmap-dev] Performance with --bounds option
> > 
> > Hi Gerd
> > 
> > With the current version I have a tile that takes 3.5 hours to
> > build.
> > With an old version (r4295) it took about 3 minutes. Without -
> > -bounds
> > it takes 1 minute 15 secs.
> > 
> > Relevant options are:
> >  --bounds=bounds.zip --location-autofill=is_in,nearest
> > 
> > 
> > From the mkgmap.log files:
> > INFO: uk.me.parabola.mkgmap.reader.osm.LocationHook
> >  ../mapGB/74220001.osm.pbf: Checking bounds dir took 66 ms
> > ...
> > INFO: uk.me.parabola.mkgmap.reader.osm.LocationHook
> >  ../mapGB/74220001.osm.pbf: Starting with location hook
> > INFO: uk.me.parabola.mkgmap.reader.osm.boundary.BoundaryUtil
> >  ../mapGB/74220001.osm.pbf: loading boundary file: bounds_265_
> > -75.bnd
> > ... about 40 similar messages ...
> > INFO: uk.me.parabola.mkgmap.reader.osm.boundary.BoundaryUtil
> >  ../mapGB/74220001.osm.pbf: loading boundary file: bounds_280_
> > -25.bnd
> > WARN: uk.me.parabola.mkgmap.reader.osm.boundary.BoundaryGrid
> >  ../mapGB/74220001.osm.pbf: no precompiled boundary information
> > available for raster tile 275_-40
> > ... 16 similar messages ...
> > WARN: uk.me.parabola.mkgmap.reader.osm.boundary.BoundaryGrid
> >  ../mapGB/74220001.osm.pbf: no precompiled boundary information
> > available for raster tile 280_-25
> > INFO: uk.me.parabola.mkgmap.reader.osm.LocationHook
> >  ../mapGB/74220001.osm.pbf: === LocationHook Stats =
> > INFO: uk.me.parabola.mkgmap.reader.osm.LocationHook
> >  ../mapGB/74220001.osm.pbf: QuadTree searches: 97834
> > INFO: uk.me.parabola.mkgmap.reader.osm.LocationHook
> >  ../mapGB/74220001.osm.pbf: unsuccesfull : 20
> > INFO: uk.me.parabola.mkgmap.reader.osm.LocationHook
> >  ../mapGB/74220001.osm.pbf: unsuccesfull for ways: 9
> > INFO: uk.me.parabola.mkgmap.reader.osm.LocationHook
> >  ../mapGB/74220001.osm.pbf: Location hook finished in 12747318 ms
> > 
> > The old version had similar lines, but the stats at the end are:
> > 
> > INFO: uk.me.parabola.mkgmap.reader.osm.LocationHook
> >  ../mapGB/74220001.osm.pbf: === LocationHook Stats =
> > INFO: uk.me.parabola.mkgmap.reader.osm.LocationHook
> >  ../mapGB/74220001.osm.pbf: QuadTree searches: 95639
> > INFO: uk.me.parabola.mkgmap.reader.osm.LocationHook
> >  ../mapGB/74220001.osm.pbf: unsuccesfull : 20
> > INFO: uk.me.parabola.mkgmap.reader.osm.LocationHook
> >  ../mapGB/74220001.osm.pbf: unsuccesfull for ways: 9
> > INFO: uk.me.parabola.mkgmap.reader.osm.LocationHook
> >  ../mapGB/74220001.osm.pbf: Location hook finished in 113704 ms
> > 
> > Ticker
> > 
> > ___
> > mkgmap-dev mailing list
> > mkgmap-dev@lists.mkgmap.org.uk
> > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> > ___
> > mkgmap-dev mailing list
> > mkgmap-dev@lists.mkgmap.org.uk
> > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Performance with --bounds option

[Ticker Berkin]

Hi Gerd

With the reversion of the code in r4469, the performance is acceptable
again. It is only a few tiles that have this problem and, for GB, they
don't add significantly to the overall map generation time

Ticker


On Thu, 2020-03-19 at 06:52 +, Gerd Petermann wrote:
> Hi Ticker,
> 
> some more details:
> I didn't think of boundary relations like r1959008 which contains >
> 700 outer rings. For each node close to that boundary mkgmap called
> Java2DConverter.areaToSingularAreas() which calculated all the areas
> again and again.
> In Germany, boundary relations typically have only one ring ;)
> I think I should look into the code which compiles bounds.zip,
> somehow I expected that those complex areas are split to singular
> areas, might improve performance.
> 
> Gerd
> 
> 
> Von: mkgmap-dev  im Auftrag
> von Gerd Petermann 
> Gesendet: Mittwoch, 18. März 2020 19:46
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Performance with --bounds option
> 
> Hi Ticker,
> 
> I forgot to remove some experimental code for is-in branch in
> BoundaryQuadTree.
> Fixed with r4469.
> I'll probably also remove the methods pointInsideArea() and
> pointInsideSingularArea() in BoundaryUtil.
> 
> Gerd
> 
> 
> Von: mkgmap-dev  im Auftrag
> von Ticker Berkin 
> Gesendet: Mittwoch, 18. März 2020 18:16
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Performance with --bounds option
> 
> Have done:
> 
> http://files.mkgmap.org.uk/download/462/74220001.osm.pbf
> 
> Ticker
> 
> On Wed, 2020-03-18 at 16:26 +, Gerd Petermann wrote:
> > Hi Ticker,
> > 
> > will look at it tomorrow. Maybe you can upload the file to
> > http://files.mkgmap.org.uk/
> > 
> > Gerd
> > 
> > 
> > Von: mkgmap-dev  im Auftrag
> > von Ticker Berkin 
> > Gesendet: Mittwoch, 18. März 2020 11:56
> > An: Development list for mkgmap
> > Betreff: Re: [mkgmap-dev] Performance with --bounds option
> > 
> > Hi Gerd
> > 
> > It's
> > 
> > 74220001: 2674688,-700416 to 2811904,-233472
> > #   : 57.392578,-15.029297 to 60.336914,-5.009766
> > 
> > Ticker
> > 
> > On Wed, 2020-03-18 at 10:46 +, Gerd Petermann wrote:
> > > Hi Ticker,
> > > 
> > > please tell me the tile boundaries
> > > 
> > > Gerd
> > > 
> > > 
> > > 
> > > Von: mkgmap-dev  im
> > > Auftrag
> > > von Ticker Berkin 
> > > Gesendet: Mittwoch, 18. März 2020 11:43
> > > An: mkgmap development
> > > Betreff: [mkgmap-dev] Performance with --bounds option
> > > 
> > > Hi Gerd
> > > 
> > > With the current version I have a tile that takes 3.5 hours to
> > > build.
> > > With an old version (r4295) it took about 3 minutes. Without -
> > > -bounds
> > > it takes 1 minute 15 secs.
> > > 
> > > Relevant options are:
> > >  --bounds=bounds.zip --location-autofill=is_in,nearest
> > > 
> > > 
> > > From the mkgmap.log files:
> > > INFO: uk.me.parabola.mkgmap.reader.osm.LocationHook
> > >  ../mapGB/74220001.osm.pbf: Checking bounds dir took 66 ms
> > > ...
> > > INFO: uk.me.parabola.mkgmap.reader.osm.LocationHook
> > >  ../mapGB/74220001.osm.pbf: Starting with location hook
> > > INFO: uk.me.parabola.mkgmap.reader.osm.boundary.BoundaryUtil
> > >  ../mapGB/74220001.osm.pbf: loading boundary file:
> > > bounds_265_
> > > -75.bnd
> > > ... about 40 similar messages ...
> > > INFO: uk.me.parabola.mkgmap.reader.osm.boundary.BoundaryUtil
> > >  ../mapGB/74220001.osm.pbf: loading boundary file:
> > > bounds_280_
> > > -25.bnd
> > > WARN: uk.me.parabola.mkgmap.reader.osm.boundary.BoundaryGrid
> > >  ../mapGB/74220001.osm.pbf: no precompiled boundary information
> > > available for raster tile 275_-40
> > > ... 16 similar messages ...
> > > WARN: uk.me.parabola.mkgmap.reader.osm.boundary.BoundaryGrid
> > >  ../mapGB/74220001.osm.pbf: no precompiled boundary information
> > > available for raster tile 280_-25
> > > INFO: uk.me.parabola.mkgmap.reader.osm.LocationHook
> > >  ../mapGB/74220001.osm.pbf: === LocationHook Stats =
> > > INFO: uk.me.parabola.mkgmap.reader.osm.LocationHook
> > >  ../mapGB/74220001.osm.pbf: Qua

Re: [mkgmap-dev] Performance with --bounds option

[Ticker Berkin]

Hi Gerd

These are the timings I get for the single tile 74220001:

trunk with --bounds=bounds.zip
 Total time taken: 3 minutes 44 seconds

r4295 with --bounds=bounds.zip
 Total time taken: 3 minutes 51 seconds

trunk with --no-bounds
 Total time taken: 1 minute 11 seconds

r4295 with --no-bounds
 Total time taken: 1 minute 6 seconds

so the latest version is about the same speed as versions before the
is_in merge.

What I meant by 'acceptable' was that the extra time for bounds
processing, although bad for this tile, is not a concern.
Building britain-and-ireland with bounds takes 36 minutes, without it
takes 29 minutes.

Ticker

On Thu, 2020-03-19 at 12:46 +, Gerd Petermann wrote:
> Hi Ticker,
> 
> when you say acceptable does that mean that latest mkgmap is still
> much slower than e.g. r4290?
> 
> Gerd
> 
> 
> Von: mkgmap-dev  im Auftrag
> von Ticker Berkin 
> Gesendet: Donnerstag, 19. März 2020 11:04
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Performance with --bounds option
> 
> Hi Gerd
> 
> With the reversion of the code in r4469, the performance is
> acceptable
> again. It is only a few tiles that have this problem and, for GB,
> they
> don't add significantly to the overall map generation time
> 
> Ticker
> 
> 
> On Thu, 2020-03-19 at 06:52 +, Gerd Petermann wrote:
> > Hi Ticker,
> > 
> > some more details:
> > I didn't think of boundary relations like r1959008 which contains >
> > 700 outer rings. For each node close to that boundary mkgmap called
> > Java2DConverter.areaToSingularAreas() which calculated all the
> > areas
> > again and again.
> > In Germany, boundary relations typically have only one ring ;)
> > I think I should look into the code which compiles bounds.zip,
> > somehow I expected that those complex areas are split to singular
> > areas, might improve performance.
> > 
> > Gerd
> > 
> > 
> > Von: mkgmap-dev  im Auftrag
> > von Gerd Petermann 
> > Gesendet: Mittwoch, 18. März 2020 19:46
> > An: Development list for mkgmap
> > Betreff: Re: [mkgmap-dev] Performance with --bounds option
> > 
> > Hi Ticker,
> > 
> > I forgot to remove some experimental code for is-in branch in
> > BoundaryQuadTree.
> > Fixed with r4469.
> > I'll probably also remove the methods pointInsideArea() and
> > pointInsideSingularArea() in BoundaryUtil.
> > 
> > Gerd
> > 
> > 
> > Von: mkgmap-dev  im Auftrag
> > von Ticker Berkin 
> > Gesendet: Mittwoch, 18. März 2020 18:16
> > An: Development list for mkgmap
> > Betreff: Re: [mkgmap-dev] Performance with --bounds option
> > 
> > Have done:
> > 
> > http://files.mkgmap.org.uk/download/462/74220001.osm.pbf
> > 
> > Ticker
> > 
> > On Wed, 2020-03-18 at 16:26 +, Gerd Petermann wrote:
> > > Hi Ticker,
> > > 
> > > will look at it tomorrow. Maybe you can upload the file to
> > > http://files.mkgmap.org.uk/
> > > 
> > > Gerd
> > > 
> > > 
> > > Von: mkgmap-dev  im
> > > Auftrag
> > > von Ticker Berkin 
> > > Gesendet: Mittwoch, 18. März 2020 11:56
> > > An: Development list for mkgmap
> > > Betreff: Re: [mkgmap-dev] Performance with --bounds option
> > > 
> > > Hi Gerd
> > > 
> > > It's
> > > 
> > > 74220001: 2674688,-700416 to 2811904,-233472
> > > #   : 57.392578,-15.029297 to 60.336914,-5.009766
> > > 
> > > Ticker
> > > 
> > > On Wed, 2020-03-18 at 10:46 +, Gerd Petermann wrote:
> > > > Hi Ticker,
> > > > 
> > > > please tell me the tile boundaries
> > > > 
> > > > Gerd
> > > > 
> > > > 
> > > > 
> > > > Von: mkgmap-dev  im
> > > > Auftrag
> > > > von Ticker Berkin 
> > > > Gesendet: Mittwoch, 18. März 2020 11:43
> > > > An: mkgmap development
> > > > Betreff: [mkgmap-dev] Performance with --bounds option
> > > > 
> > > > Hi Gerd
> > > > 
> > > > With the current version I have a tile that takes 3.5 hours to
> > > > build.
> > > > With an old version (r4295) it took about 3 minutes. Without -
> > > > -bounds
> > > > it takes 1 minute 15 secs.
> > > > 
&g

Re: [mkgmap-dev] Commit r4470: genSea.patch by Ticker Berkin

[Ticker Berkin]

Hi Mike

Errors like are normally because the tile is at the edge of your
downloaded area and includes incomplete coastline that doesn't reach
the tile edge and/or has gaps where there are estuaries, harbours, etc.

If this is not the case then there are either errors in the
natural=coastline data or in the logic of SeaGenerator.java

Depending on your --generate-sea options, the code tries to resolve
this in different manners (sea-sectors, extend-sea-sectors, no-sea
-sectors). None of these are guaranteed to work, but I tried to improve
it so that it was more likely that sea was land-flooded rather than the
other way around.

What are you generate-sea options. I've found that:
 --generate-sea=multipolygon,extend-sea-sectors,close-gaps=500
works well most of the time

Ticker


On Fri, 2020-03-20 at 07:34 +, Mike Baggaley wrote:
> Just noticed the log file has the following in it:
> 
>  66973072.o5m: Adjacent coastlines hit tile edge in same direction
> 3.512082099914551 null
>  66973072.o5m: Adjacent coastlines hit tile edge in same direction
> 3.904301643371582 WAY: 4611686018492528634 null(50.39497375488281/
> -3.603515625) []
> 
> This is the offending tile, although there are other tiles showing
> the same message:
> 
>   66973028.o5m: Adjacent coastlines hit tile edge in same direction
> 3.68414306640625 null
>   66973028.o5m: Adjacent coastlines hit tile edge in same direction
> 3.6845932006835938 WAY: 4611686018454067807
> null(51.540770530700684/0.5712890625) []
>   66973031.o5m: Adjacent coastlines hit tile edge in same direction
> 1.3157111273871527 null
>   66973031.o5m: Adjacent coastlines hit tile edge in same direction
> 1.5220565795898438 WAY: 4611686018456515937
> null(51.62250280380249/0.5712890625) []
>   66973063.o5m: Adjacent coastlines hit tile edge in same direction
> 0.964984130859375 null
>   66973063.o5m: Adjacent coastlines hit tile edge in same direction
> 0.968072509765625 WAY: 4611686018481807136 null(50.8447265625/
> -1.112666130065918) []
>   66973064.o5m: Adjacent coastlines hit tile edge in same direction
> 2.0334129333496094 null
>   66973064.o5m: Adjacent coastlines hit tile edge in same direction
> 2.1257583618164064 WAY: 4611686018481855529 null(50.8447265625/
> -1.1539077758789062) []
>   66973071.o5m: Adjacent coastlines hit tile edge in same direction
> 1.4875097274780273 null
>   66973071.o5m: Adjacent coastlines hit tile edge in same direction
> 1.493368148803711 WAY: 4611686018490569733 null(50.534770488739014/
> -3.603515625) []
>   66973216.o5m: Adjacent coastlines hit tile edge in same direction
> 3.6122945149739585 null
>   66973216.o5m: Adjacent coastlines hit tile edge in same direction
> 3.6950721740722656 WAY: 4611686018642067673 null(54.13313627243042/
> -2.8125) []
>   66973233.o5m: Adjacent coastlines hit tile edge in same direction
> 1.8426347620346966 null
>   66973233.o5m: Adjacent coastlines hit tile edge in same direction
> 1.9191019394818474 WAY: 4611686018657352840 null(54.21201467514038/
> -2.8125) []
> 
> Do these messages indicate errors in the coastline data?
> 
> Regards,
> Mike
> 
> -Original Message-
> From: Mike Baggaley [mailto:m...@tvage.co.uk] 
> Sent: 19 March 2020 23:44
> To: mkgmap-dev@lists.mkgmap.org.uk
> Subject: Re: [mkgmap-dev] Commit r4470: genSea.patch by Ticker Berkin
> 
> Hi Gerd & Ticker,
> 
> Whilst I was testing Ticker's patch, Gerd's update was committed, so
> I am slightly behind the times. Both the patch and the committed code
> have solved almost all my coastline problems. Thanks for your
> efforts. I now have no tiles that are being filled with sea, but I do
> have one tile that is now displaying the opposite problem, in that it
> now displays all land and no sea with both code versions, even though
> there is a significant amount of sea. Please see the attached
> screenshot. I would have attached the tile, but it is rather large
> for emailing.
> 
> Cheers,
> Mike
> 
> -Original Message-
> From: svn commit [mailto:s...@mkgmap.org.uk] 
> Sent: 18 March 2020 18:23
> To: mkgmap-...@lists.mkgmap.org.uk; mkgmap-dev@lists.mkgmap.org.uk
> Subject: [mkgmap-dev] Commit r4470: genSea.patch by Ticker Berkin
> 
> Version mkgmap-r4470 was committed by gerd on Wed, 18 Mar 2020
> 
> genSea.patch by Ticker Berkin
> fixes flooded areas caused by changes in r4392 and other issues with
> unclosed coastlines 
> 
> http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4470
> 
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Commit r4470: genSea.patch by Ticker Berkin

[Ticker Berkin]

Hi Mike

Another question:

Was the image attached to the first mail a single tile?

Ticker


On Fri, 2020-03-20 at 09:39 +, Ticker Berkin wrote:
> Hi Mike
> 
> Errors like are normally because the tile is at the edge of your
> downloaded area and includes incomplete coastline that doesn't reach
> the tile edge and/or has gaps where there are estuaries, harbours,
> etc.
> 
> If this is not the case then there are either errors in the
> natural=coastline data or in the logic of SeaGenerator.java
> 
> Depending on your --generate-sea options, the code tries to resolve
> this in different manners (sea-sectors, extend-sea-sectors, no-sea
> -sectors). None of these are guaranteed to work, but I tried to
> improve
> it so that it was more likely that sea was land-flooded rather than
> the
> other way around.
> 
> What are you generate-sea options. I've found that:
>  --generate-sea=multipolygon,extend-sea-sectors,close-gaps=500
> works well most of the time
> 
> Ticker
> 
> 
> On Fri, 2020-03-20 at 07:34 +, Mike Baggaley wrote:
> > Just noticed the log file has the following in it:
> > 
> >  66973072.o5m: Adjacent coastlines hit tile edge in same direction
> > 3.512082099914551 null
> >  66973072.o5m: Adjacent coastlines hit tile edge in same direction
> > 3.904301643371582 WAY: 4611686018492528634 null(50.39497375488281/
> > -3.603515625) []
> > 
> > This is the offending tile, although there are other tiles showing
> > the same message:
> > 
> >   66973028.o5m: Adjacent coastlines hit tile edge in same direction
> > 3.68414306640625 null
> >   66973028.o5m: Adjacent coastlines hit tile edge in same direction
> > 3.6845932006835938 WAY: 4611686018454067807
> > null(51.540770530700684/0.5712890625) []
> >   66973031.o5m: Adjacent coastlines hit tile edge in same direction
> > 1.3157111273871527 null
> >   66973031.o5m: Adjacent coastlines hit tile edge in same direction
> > 1.5220565795898438 WAY: 4611686018456515937
> > null(51.62250280380249/0.5712890625) []
> >   66973063.o5m: Adjacent coastlines hit tile edge in same direction
> > 0.964984130859375 null
> >   66973063.o5m: Adjacent coastlines hit tile edge in same direction
> > 0.968072509765625 WAY: 4611686018481807136 null(50.8447265625/
> > -1.112666130065918) []
> >   66973064.o5m: Adjacent coastlines hit tile edge in same direction
> > 2.0334129333496094 null
> >   66973064.o5m: Adjacent coastlines hit tile edge in same direction
> > 2.1257583618164064 WAY: 4611686018481855529 null(50.8447265625/
> > -1.1539077758789062) []
> >   66973071.o5m: Adjacent coastlines hit tile edge in same direction
> > 1.4875097274780273 null
> >   66973071.o5m: Adjacent coastlines hit tile edge in same direction
> > 1.493368148803711 WAY: 4611686018490569733 null(50.534770488739014/
> > -3.603515625) []
> >   66973216.o5m: Adjacent coastlines hit tile edge in same direction
> > 3.6122945149739585 null
> >   66973216.o5m: Adjacent coastlines hit tile edge in same direction
> > 3.6950721740722656 WAY: 4611686018642067673 null(54.13313627243042/
> > -2.8125) []
> >   66973233.o5m: Adjacent coastlines hit tile edge in same direction
> > 1.8426347620346966 null
> >   66973233.o5m: Adjacent coastlines hit tile edge in same direction
> > 1.9191019394818474 WAY: 4611686018657352840 null(54.21201467514038/
> > -2.8125) []
> > 
> > Do these messages indicate errors in the coastline data?
> > 
> > Regards,
> > Mike
> > 
> > -Original Message-
> > From: Mike Baggaley [mailto:m...@tvage.co.uk] 
> > Sent: 19 March 2020 23:44
> > To: mkgmap-dev@lists.mkgmap.org.uk
> > Subject: Re: [mkgmap-dev] Commit r4470: genSea.patch by Ticker
> > Berkin
> > 
> > Hi Gerd & Ticker,
> > 
> > Whilst I was testing Ticker's patch, Gerd's update was committed,
> > so
> > I am slightly behind the times. Both the patch and the committed
> > code
> > have solved almost all my coastline problems. Thanks for your
> > efforts. I now have no tiles that are being filled with sea, but I
> > do
> > have one tile that is now displaying the opposite problem, in that
> > it
> > now displays all land and no sea with both code versions, even
> > though
> > there is a significant amount of sea. Please see the attached
> > screenshot. I would have attached the tile, but it is rather large
> > for emailing.
> > 
> > Cheers,
> > Mike
> > 
> > -Original Message-
> > From: svn commit [mailto:s...@mkgmap.org.uk] 
> &g

Re: [mkgmap-dev] Commit r4470: genSea.patch by Ticker Berkin

[Ticker Berkin]

Hi Mike, Gerd

I've also built 66973072.o5m from 
http://files.mkgmap.org.uk/download/463/66973072.zip

and don't get any of the messages about the coastline hitting tile edge
in the same direction.

With --generate-sea=multipolygon it look correct.

With --generate-sea=polygon it requires more in the style and .typ fileto get 
the land to show over the sea because this mode generates a polygon tagged 
natural=sea covering the full tile and then, for each but of land, a polygon 
tagged with --land-tag (default natural=land) 

Ticker

On Sat, 2020-03-21 at 08:44 +, Gerd Petermann wrote:
> Hi Mike,
> 
> I cannot reproduce the problem with r4473 and your file and option -
> -generate-sea=multipolygon.
> I can reproduce it with option --generate-sea=polygon, but that
> option is not recommended AFAIK.
> 
> Gerd
> 
> 
> Von: mkgmap-dev  im Auftrag
> von Mike Baggaley 
> Gesendet: Freitag, 20. März 2020 23:18
> An: 'Development list for mkgmap'
> Betreff: Re: [mkgmap-dev] Commit r4470: genSea.patch by Ticker Berkin
> 
> Close inspection shows a very small coast outline of an outcrop at
> N50.45154 W3.55078 that may not be a valid polygon, another at
> N50.40129 W3.49404, and another at 50.39544 W3.51977, also, possible
> loops in the main coastline at N50.34285 W3.56060, N50.36633
> W3.57717, N50.36740 W 3.57671, N50.37806 W 3.58133, N50.34436
> W3.57435 and N50.33140 W3.56933. Also, what looks like a spur at
> N50.70210 W3.50376. The problem seems to depend on where the tile
> borders are - If I delete everything except the coastline data and
> process that through splitter and mkgmap, there are far fewer tiles
> and the result looks pretty well perfect as far as I can see.
> 
> Regards,
> Mike
> 
> 
> -Original Message-
> From: Mike Baggaley [mailto:m...@tvage.co.uk]
> Sent: 20 March 2020 21:35
> To: 'Development list for mkgmap' 
> Subject: RE: [mkgmap-dev] Commit r4470: genSea.patch by Ticker Berkin
> 
> Hi Ticker,
> 
> The image was contained more than a single tile - the tile I was
> referring to was a rectangle of which the white area was the bottom
> right corner. The second image shows the border between that tile (on
> the right) and the adjacent tile on the left. The original tile did
> in fact contain some sea correctly rendered in an inlet originating
> at Kingswear which is just on the edge of the white area.
> 
> I used just generate-sea without any of the other options this time,
> but have used extend-sea-vectors and close-gaps without any obvious
> effect. I suspect that the problem with my outline is not that there
> are gaps, but that there may be loops where the coastline crosses
> itself.
> 
> Regards,
> Mike
> 
> -Original Message-
> From: Ticker Berkin [mailto:rwb-mkg...@jagit.co.uk]
> Sent: 20 March 2020 09:45
> To: Development list for mkgmap 
> Subject: Re: [mkgmap-dev] Commit r4470: genSea.patch by Ticker Berkin
> 
> Hi Mike
> 
> Another question:
> 
> Was the image attached to the first mail a single tile?
> 
> Ticker
> 
> 
> On Fri, 2020-03-20 at 09:39 +, Ticker Berkin wrote:
> > Hi Mike
> > 
> > Errors like are normally because the tile is at the edge of your
> > downloaded area and includes incomplete coastline that doesn't
> > reach
> > the tile edge and/or has gaps where there are estuaries, harbours,
> > etc.
> > 
> > If this is not the case then there are either errors in the
> > natural=coastline data or in the logic of SeaGenerator.java
> > 
> > Depending on your --generate-sea options, the code tries to resolve
> > this in different manners (sea-sectors, extend-sea-sectors, no-sea
> > -sectors). None of these are guaranteed to work, but I tried to
> > improve
> > it so that it was more likely that sea was land-flooded rather than
> > the
> > other way around.
> > 
> > What are you generate-sea options. I've found that:
> >  --generate-sea=multipolygon,extend-sea-sectors,close-gaps=500
> > works well most of the time
> > 
> > Ticker
> > 
> > 
> > On Fri, 2020-03-20 at 07:34 +, Mike Baggaley wrote:
> > > Just noticed the log file has the following in it:
> > > 
> > >  66973072.o5m: Adjacent coastlines hit tile edge in same
> > > direction
> > > 3.512082099914551 null
> > >  66973072.o5m: Adjacent coastlines hit tile edge in same
> > > direction
> > > 3.904301643371582 WAY: 4611686018492528634
> > > null(50.39497375488281/
> > > -3.603515625) []
> > > 
> > > This is the offending tile, althou

Re: [mkgmap-dev] Commit r4470: genSea.patch by Ticker Berkin

[Ticker Berkin]

Hi Mike

Also, why are you using this?

If --generate-sea=... (without --coastlinefile) is having problems
around your map edge because of incomplete coastlines, the better
solution is to use --precomp-sea=sea.zip instead; where sea.zip is
downloaded from link on the mkgmap site.

whatever the source of the data for generate-sea, it the tile edge cuts
through a loop or crossing coastlines, or a bit of coastline goes in
the wrong direction, it might produce errors like:

"Adjacent coastlines hit tile edge in same direction"

and flood the land or drain the sea.

Incomplete coastlines because they are outside the downloaded area, but
included in a tile might be impossible for --generate-sea to resolve,
but the options close-gaps, sea-sectors and extend-sea-sectors might
give a reasonable of the land/sea

Ticker

On Sun, 2020-03-22 at 09:52 +, Gerd Petermann wrote:
> Hi Mike,
> 
> took me a while to load the file into JOSM. The file contains lots of
> errors, how is it produced?
> I doubt that the real coastline data is as bad as this.
> JOSM validator finds lots of duplicated nodes,  1673 ways with
> "Reversed coastline: land not on left side", and 859 "Crossing ways".
> 
> Gerd
> 
> 
> Von: mkgmap-dev  im Auftrag
> von Mike Baggaley 
> Gesendet: Samstag, 21. März 2020 23:13
> An: 'Development list for mkgmap'
> Betreff: Re: [mkgmap-dev] Commit r4470: genSea.patch by Ticker Berkin
> 
> Hi Gerd & Ticker,
> 
> Please accept my apologies - I forgot that the coastline data I was
> using
> would not be in the tile data because I have a --coastlinefile option
> in my
> command arguments. I have uploaded the coastline file now.
> 
> Regards,
> Mike
> 
> -Original Message-
> From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com]
> Sent: 21 March 2020 08:45
> To: 'Development list for mkgmap' 
> Subject: Re: [mkgmap-dev] Commit r4470: genSea.patch by Ticker Berkin
> 
> Hi Mike,
> 
> I cannot reproduce the problem with r4473 and your file and option
> --generate-sea=multipolygon.
> I can reproduce it with option --generate-sea=polygon, but that
> option is
> not recommended AFAIK.
> 
> Gerd
> 
> 
> Von: mkgmap-dev  im Auftrag
> von Mike
> Baggaley 
> Gesendet: Freitag, 20. März 2020 23:18
> An: 'Development list for mkgmap'
> Betreff: Re: [mkgmap-dev] Commit r4470: genSea.patch by Ticker Berkin
> 
> Close inspection shows a very small coast outline of an outcrop at
> N50.45154
> W3.55078 that may not be a valid polygon, another at N50.40129
> W3.49404, and
> another at 50.39544 W3.51977, also, possible loops in the main
> coastline at
> N50.34285 W3.56060, N50.36633 W3.57717, N50.36740 W 3.57671,
> N50.37806 W
> 3.58133, N50.34436 W3.57435 and N50.33140 W3.56933. Also, what looks
> like a
> spur at N50.70210 W3.50376. The problem seems to depend on where the
> tile
> borders are - If I delete everything except the coastline data and
> process
> that through splitter and mkgmap, there are far fewer tiles and the
> result
> looks pretty well perfect as far as I can see.
> 
> Regards,
> Mike
> 
> 
> -Original Message-
> From: Mike Baggaley [mailto:m...@tvage.co.uk]
> Sent: 20 March 2020 21:35
> To: 'Development list for mkgmap' 
> Subject: RE: [mkgmap-dev] Commit r4470: genSea.patch by Ticker Berkin
> 
> Hi Ticker,
> 
> The image was contained more than a single tile - the tile I was
> referring
> to was a rectangle of which the white area was the bottom right
> corner. The
> second image shows the border between that tile (on the right) and
> the
> adjacent tile on the left. The original tile did in fact contain some
> sea
> correctly rendered in an inlet originating at Kingswear which is just
> on the
> edge of the white area.
> 
> I used just generate-sea without any of the other options this time,
> but
> have used extend-sea-vectors and close-gaps without any obvious
> effect. I
> suspect that the problem with my outline is not that there are gaps,
> but
> that there may be loops where the coastline crosses itself.
> 
> Regards,
> Mike
> 
> -Original Message-
> From: Ticker Berkin [mailto:rwb-mkg...@jagit.co.uk]
> Sent: 20 March 2020 09:45
> To: Development list for mkgmap 
> Subject: Re: [mkgmap-dev] Commit r4470: genSea.patch by Ticker Berkin
> 
> Hi Mike
> 
> Another question:
> 
> Was the image attached to the first mail a single tile?
> 
> Ticker
> 
> 
> On Fri, 2020-03-20 at 09:39 +, Ticker Berkin wrote:
> > Hi Mike
> > 
> > Errors like are nor

Re: [mkgmap-dev] Errors converting "mapnik.txt" into "mapnik.typ" (information only)

[Ticker Berkin]

Hi Eric

I use mkgmap to convert typ-files from .txt to .typ (just stick
mapnik.txt at the end of the parameter list, after the map data files)
It doesn't give these errors.

Line 1959 - is TYPViewer objecting to "String=River..." because it
wants something of the form "String1=0x00,River..." or is it objecting
to the "," between River & Wadi?

Polygon 0x3d errors - Not sure what it doesn't like here, maybe the
indentation, as this is a significant thing different about it from,
say, 0x04. This polygon should be transparent - there was a long debate
about this at the beginning of the year. The only way to do this is
with a ICON.

From my experiments, Garmin devices expect the TYP section to be in the
same character-set as the map to which it is attached. Using mkgmap to
do the conversion handles this. mapnik.txt needs to be in some unicode
encoding as it encompasses many languages; if TYPViewer doesn't allow
you to save in the required char-set then this is a fundamental problem
in using TYPViewer to do the conversion. 

Ticker

On Wed, 2020-03-25 at 07:38 -0700, AnkEric wrote:
> mapnik.txt (128.746 bytes,19-03-2020 08:31)
> 
> I assume (...) "mapnik.txt" is to be converted into ".typ".
> 
> Using TYPViewer 4.5.50 two Errors during conversion:
> 
> 
> Errors in the file  : mapnik.txt
> 
> 
> Line 1959 : "String=River, Wadi (Intermittent)"
> 
> To Resolve, update:
> String=River, Wadi (Intermittent)
> into:
> String1=0x00,River (Intermittent)
> String2=0x01,Cours d’eau (intermittent)
> etc.
> 
> 
> Errors in the file  : 44010.typ
> 
> 
> Error while reading polygon 0x03d/00 : Error #9   Description:
> Subscript out
> of range
> Error while reading polygon 0x03d/00 : Error #9   Description:
> Subscript out
> of range
> Error while reading polygon 0x03d/00 : Error #9   Description:
> Subscript out
> of range
> Error in the length of the polygon Type=0x03d   SubType=0x00
> Problem with the polygon Type=0x03d   SubType=0x00
> 
> To Resolve: copy from Type=0x3c
> 
> [_polygon]
> Type=0x3d
> ;GRMN_TYPE: Water Areas/LAKE_30MI, LARGE_LAKE/Large lake, typically
> between
> 30 and 500 sq mi in area/Non NT
> String1=0x00,Bay
> String2=0x01,Baie
> String3=0x02,Bucht
> String4=0x03,Baai
> String5=0x15,Zatoka
> String6=0x10,Baia
> String7=0x05,Baia
> ExtendedLabels=Y
> FontStyle=SmallFont
> CustomColor=Day
> DaycustomColor:#4D80B3
> Xpm="0 0 1 0"
> "1 c #AAD3DF"
> [end]
> 
> Also be aware:
> mapnik.txt is [UTF-8] encoding
> I assume (...) Garmin expects [Windows 1252] encoding.
> If [Windows 1252] is required, in TYPViewer "Open a TXT (Utf8)
> file...".
> Converted TYP file will have same encoding.
> 
> 
> 
> --
> Sent from: 
> http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Errors converting "mapnik.txt" into "mapnik.typ" (information only)

[Ticker Berkin]

Here is a patch for mapnik.txt that:
- removes a "," from a default string.
- doesn't indent the Bay Xpm section.
- fixes a spelling mistake.

The first 2 changes might stop errors when TYPViewer reads the file

Ticker


On Wed, 2020-03-25 at 08:56 -0700, AnkEric wrote:
> Hi Ticker,
> 
> > Line 1959 - is TYPViewer objecting to "String=River..." because it
> wants something of the form "String1=0x00,River..." or is it
> objecting
> to the "," between River & Wadi?
> 
> This is "acceptable" to TYPViewer:
> String=River Wadi (Intermittent)
> String1=0x01,Cours d’eau (intermittent)
> 
> So (...?) for "unspecified language" (default??) TYPViewer doesn't
> like csv.
> 
> Next TYPViewer will "renumber", so this was not the issue:
> String1=0x00,River Wadi (Intermittent)
> String2=0x01,Cours d’eau (intermittent)
> 
> > Polygon 0x3d errors - Not sure what it doesn't like here
> 
> I don't know either, I just resolved "Quick and (very) Dirty" because
> I
> wanted a proof of concept for a "mapnik"-Map.
> 
> > This polygon should be transparent
> 
> Oké, thanks. Now I have the challenge to use mkgmap to convert typ
> -files
> from .txt to .typ, find a "bay" (have I ever seen one in real life??)
> and
> hopefully I will understand "the long debate".
> 
> > if TYPViewer doesn't allow you to save in the required char-set
> > then this
> > is a fundamental problem
> in using TYPViewer to do the conversion.
> 
> TYPViewer will Save utf8 As utf8 and Save 1252 As 1252. So the
> encoding of
> my source file is leading.
> So I have a work-around.
> 
> Eric (AnkEric)
> 
> 
> 
> --
> Sent from: 
> http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-devIndex: resources/typ-files/mapnik.txt
===
--- resources/typ-files/mapnik.txt	(revision 4474)
+++ resources/typ-files/mapnik.txt	(working copy)
@@ -768,41 +768,41 @@
 FontStyle=NoLabel (invisible)
 CustomColor=No
 Xpm="32 32 2 1"
-". c none"
-"1 c #FF"
-""
-""
-""
-""
-""
-""
-""
-""
-""
-""
-""
-""
-""
-""
-""
-""
-""
-""
-""
-""
-""
-""
-""
-""
-""
-""
-""
-""
-""
-""
-""
-""
-;   "12345678901234567890123456789012"
+". c none"
+"1 c #FF"
+""
+""
+""
+""
+""
+""
+""
+""
+""
+""
+""
+""
+""
+""
+""
+""
+""
+""
+""
+""
+""
+""
+""
+""
+""
+""
+""
+""
+""
+""
+""
+""
+;12345678901234567890123456789012
 [end]
 [_polygon]
 type=0x3f
@@ -1956,7 +1956,7 @@
 " !!  !!  !!  !!  !!  !!  !!  !! "
 " !!  !!  !!  !!  !!  !!  !!  !! "
 ;12345678901234567890123456789012
-String=River, Wadi (Intermittent)
+String=River/Wadi (Intermittent)
 String1=0x01,Cours d’eau (intermittent)
 String2=0x02,Fluß (Periodisch)
 String

Re: [mkgmap-dev] Errors converting "mapnik.txt" into "mapnik.typ" (information only)

[Ticker Berkin]

Hi Eric

The problem with using TYPViewer to change the file is that it has made
lots of arbitary/irrelevant textual changes, lost information about the
source encoding, added information about the destination encoding,
removed the comments, etc

This is fine for your usage, but not for changing the file in the
mkgmap repository.

Is there a change that you'd like to see in the next version?

Ticker

On Wed, 2020-03-25 at 15:41 -0700, AnkEric wrote:
> 1. Open "mapnik.txt" in TYPViewer
> 2. Edit: Type=0x3d
> 3. Update Colors, Day and Night: from #00 to #FF
> 4. Different Colors for Night = yes (!!!)
> 5. Different Colors for Night = NO (!!!)
> 6. Save
> 7. Done
> 
>  
> 
> Attached: "mapnik_FIX.txt"
> 
> mapnik_FIX.txt <
> http://gis.19327.n8.nabble.com/file/t344065/mapnik_FIX.txt>  ;
> 
> Eric (AnkEric)
> 
> 
> 
> --
> Sent from: 
> http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Errors converting "mapnik.txt" into "mapnik.typ" (information only)

[Ticker Berkin]

Hi Eric / Gerd

I've changed the characters used to represent the pixels in the bay
icon. I've just loaded TYPViewer and used it to convert latest
mapnik.txt to mapnik.typ. It seemed quite happy to do this, but when
using TYPViewer to read back the .typ file, it gives the errors:

Error while reading polygon 0x03d/00 : Error #9   Description:
Subscript out of range
...

This patch stop this happening.

I also suspect TYPViewer character-set conversions. Looking at a
supposed 1251 .typ file, there were unicode characters in the strings.

I'll look the rest of your email later and respond.

Ticker


On Thu, 2020-03-26 at 05:46 -0700, AnkEric wrote:
> Hi Ticker,
> 
> /> Is there a change that you'd like to see in the next version?/
> 
> No, thanks.
> Please consider: I'm only a private user. Therefore my RFC's or
> suggestions
> are only relevant if other users might benefit as well.
> 
> My conclusion (FWIW):
> Use "mapnik_fix.txt", update with Comments (restore lost
> information),
> rename to "mapnik.txt" and save in mkgmap repository.
> Next version: verify "mkgmap.txt" to be compliant, compatible with
> TYPViewer.
> Yes, this would be a change I'd like to see in the next version!
> 
> But first: verify if ([_polygon] type=0x3d, Bay) is okay for mkgmap
> if
> TYPViewer changes are applied.
> Anke does not know what (natural=bay) is, where to find it (it's not
> in the
> Netherlands) and how to verify if it's up to mkgmap standards. A
> [natural=bay] is on top of the water? Similarly to [leisure=marina]?
> And
> should be rendered by name only?
> OT? Yes and No, since the "bay" took me an hour of billable work
> yesterday.
> Moreover, Anke is wondering why [natural=bay] is explicitly rendered
> by
> mkgmap-default and (wetland=swamp) is not rendered by mkgmap-default.
> Disappointing to say the least.
> Or why (natural=wetland & name=*) and (natural=wetland & name!=*) are
> rendered differently? Hiding "wetland" as "meadow" if wetland is
> having a
> name? 
> 
> /> This is fine for your usage, but not for changing the file in the
> mkgmap
> repository./
> 
> IMO, mkgmap - as a Global Application, having Global Users - needs a
> very
> good reason for not being compliant. In this context being not
> compliant to
> TYPViewer.
> "Change typfile (easy using TYPViewer) is your first option if you
> don't
> like the OSM-Map" is a suggestion I have made very often to
> dissatisfied
> users.
> Also for me: If I should want to change mkgmap.txt it's most simple
> by
> updating mkgmap.txt by TYPViewer, without having to Resolve the one
> (!)
> remaining "Error" or "Syntax difference" ([_polygon] type=0x3d)
> first.
> 
> /> The problem with using TYPViewer to change the file is that it has
> made
> lots of arbitary/irrelevant textual changes, lost information about
> the
> source encoding, added information about the destination encoding,
> removed
> the comments, etc/
> 
> Fact or fable?
> 
> Yes, TYPViewer did "remove the comments" (if "mkgmap.txt" is
> converted to
> ".txt", but why would a user want to do this?).
> If comments are added to mkgmap.txt, a User can see the comments.
> Once a
> User or mkgmap will update "mkgmap.txt" to "mkgmap.typ" this
> information is
> lost, but also not required for Compiling the Map. All Compilers will
> always
> remove all comments in SourceCode.
> TYPViewer will generate a TXT file from the Compiled version (if
> requested),
> therefore Comments are removed, except for TYPViewer's own Comments.
> And since this - IMO - is the only drawback for TYPViewer: have we
> ever
> suggested this as a RFC to sherc...@ntymail.com ? Sherco has updated
> TYPViewer in my interest in the past.
> 
> mkgmap.txt:
> 
> [_id]
> /;ProductCode=1   set from --product-id
> ;FID=8094set from --family-id
> ;CodePage=65001  set from --code-page/
> 
> If I Change this into the next lines, TYPViewer will respect that,
> therefore
> no "lost information about the source encoding":
> [_id]
> ProductCode=1
> FID=8094
> CodePage=65001
> 
> If I don't Set encoding (in "mapnik.txt"), I can set it inside
> TYPViewer:
> 
>  
> 
> Encoding:
> TXT file mapnik is: "utf-8 BOM, Unix (Lf)" 
> /; -*- coding: UTF-8 -*- NB: first 3 bytes/char in file is UTF-8
> encoded
> ByteOrderMark (BOM)/
> TXT file TYPViewer is: "utf-8, Win (CrLf)"
> 
> *Fact checking:*
> Compare "mkgmap.txt" and "mkgmap_fix.txt " and look for
> "arbitrary/irrelevant textual changes".
> To do so, Professionally I use UltraEdit and UltraCompare.
> Privately I use EditPad Lite (free for personal use) and  WinMerge
> (free
> software). Both highly recommended for OSM, mkgmap.
> 
>  p_TYPViewer.png> 
> 
> 1. TYPViewer will remove Comments:
> ;Author: jori...@hotmail.com
> ;
> ;Based on mkgmap default style version: r4293...4288
> ;
> Etc.
> 
> 2. TYPViewer will add more Comments:
> ;=== POLYGONE

Re: [mkgmap-dev] Errors converting "mapnik.txt" into "mapnik.typ" (information only)

[Ticker Berkin]

Hi Eric

see embedded

Ticker

On Thu, 2020-03-26 at 05:46 -0700, AnkEric wrote:
> Hi Ticker,
> 
> /> Is there a change that you'd like to see in the next version?/
> 
> No, thanks.
> Please consider: I'm only a private user. Therefore my RFC's or
> suggestions
> are only relevant if other users might benefit as well.
> 
> My conclusion (FWIW):
> Use "mapnik_fix.txt", update with Comments (restore lost
> information),
> rename to "mapnik.txt" and save in mkgmap repository.
> Next version: verify "mkgmap.txt" to be compliant, compatible with
> TYPViewer.
> Yes, this would be a change I'd like to see in the next version!
> 
> But first: verify if ([_polygon] type=0x3d, Bay) is okay for mkgmap
> if
> TYPViewer changes are applied.

Bay needs to be transparent. Changing the characters use to represent
the pixels works around the TYPViewer problem.

> Anke does not know what (natural=bay) is, where to find it (it's not
> in the
> Netherlands)

my old NL map had this:
 51.34878873825073/3.7353515625 [name=Slufter Kwade Hoek, natural=bay] 
and these two named bays still exist
 https://www.openstreetmap.org/relation/3123125
 https://www.openstreetmap.org/relation/1305743

>  and how to verify if it's up to mkgmap standards. A
> [natural=bay] is on top of the water?

A bay area will often include islands, so it must not hide these and
the islands shouldn't be cut-out from the bay with a multipolygon
relation. The reason for the polygon is for naming the area so the
default style should be changed so the rule only triggers if named.

>  Similarly to [leisure=marina]? And
> should be rendered by name only?

this is not in the default style at the moment, but could be added
(even if unnamed - it is a visible feature)

> OT? Yes and No, since the "bay" took me an hour of billable work
> yesterday.

?

> Moreover, Anke is wondering why [natural=bay] is explicitly rendered
> by
> mkgmap-default and (wetland=swamp) is not rendered by mkgmap-default.

wetland=swamp should only occur in conjunction with natural=wetland,
which is handled by the mkgmap-default. Many of the decisions about
what is handled by mkgmap-default are based on the standard TYPs
supported by a typical Garmin device

> Disappointing to say the least.
> Or why (natural=wetland & name=*) and (natural=wetland & name!=*) are
> rendered differently?

mkgmap-default doesn't do this

>  Hiding "wetland" as "meadow" if wetland is having a
> name? 

I don't understand what you mean. I don't see anything in mkgmap
-default that relates to this

> 
> /> This is fine for your usage, but not for changing the file in the
> mkgmap
> repository./
> 
> IMO, mkgmap - as a Global Application, having Global Users - needs a
> very
> good reason for not being compliant. In this context being not
> compliant to
> TYPViewer.
> "Change typfile (easy using TYPViewer) is your first option if you
> don't
> like the OSM-Map" is a suggestion I have made very often to
> dissatisfied
> users.

It might be easy, but it changes the file in ways that may cause
incorrect behaviour, and in a typical file that hasn't been maintained
by TYPViewer, it might change every section. Another tool my behave in
a similar manner and feel free re-write the file in a different way;
then it would quickly become impossible to know what is significant for
any required changes.


> 
> Also for me: If I should want to change mkgmap.txt it's most simple
> by
> updating mkgmap.txt by TYPViewer, without having to Resolve the one
> (!)
> remaining "Error" or "Syntax difference" ([_polygon] type=0x3d)
> first.

The line that caused the TYPViewer input error has been changed in
mkgmap. The other line that exposes a problem in TYPViewer should be be
applied soon. It is difficult to predict the problems that other .typ
manipulation tools might have.

> 
> /> The problem with using TYPViewer to change the file is that it has
> made
> lots of arbitary/irrelevant textual changes, lost information about
> the
> source encoding, added information about the destination encoding,
> removed
> the comments, etc/
> 
> Fact or fable?

Look at the saved .txt file

> Yes, TYPViewer did "remove the comments" (if "mkgmap.txt" is
> converted to
> ".txt", but why would a user want to do this?).

Because they want to use TYPViewer to make changed to the mkgmap
resources/typ-files/*.txt

> If comments are added to mkgmap.txt, a User can see the comments.
> Once a
> User or mkgmap will update "mkgmap.txt" to "mkgmap.typ" this
> information is
> lost, but also not required for Compiling the Map.

This is obvious

>  All Compilers will always
> remove all comments in SourceCode.

Which compiler removes comments from the source code? Almost all won't
copy the comments into the object format.

> TYPViewer will generate a TXT file from the Compiled version (if
> requested),
> therefore Comments are removed, except for TYPViewer's own Comments.
> And since this - IMO - is the only drawback for TYPViewer: have we
> ever
> suggested t

Re: [mkgmap-dev] Errors converting "mapnik.txt" into "mapnik.typ" (information only)

[Ticker Berkin]

Hi Eric

There is a lot here!

I don't want to spend a lot of time going through it point by point
here are some comments and some changes, helpful to TYPViewer users,
that could be made to mapnik.txt and mkgmap.

1/ DONE: remove a comma from a STRING default line. This is because
mkgmap and TYPViewer use different parsing methods for:
   String[#]=[lang#,]description
where [] indicates optional. mkgmap spots there is no language#

2/ PATCH in progress: Change a character used to represent a pixel
colour. These characters are arbitrary, but something, either the . or
the 1, causes TYPViewer to write an incorrect .typ file

3/ pixel characters can be chosen by the user; it is NOT an error to
use different characters per icon. TYPViewer changes them to the
characters it would use if it was reading a binary .typ file.

4/ Implement the [_comments] ... [end] section in mkgmap. These
comments wouldn't put it into the .typ file unlike TYPViewer, which
does. It is good for copyright and version information but not actual
comments. Having experimented with this I find that TYPViewer is
inconsistent when reading it back and sometimes reports a different
header length and doesn't pick up the comments.

5/ What I meant by "supposed Win 1252 Typ file" is that it is very easy
to get TYPViewer to generate a file where the Typ header says the
CodePage is 1252, but the strings are encoded as utf8 hence chars>127
will show incorrectly.
I was going try list some of the ways to get it correct and some that
get it wrong, but there are many variables that might have an effect on
this I'm finding this a time-consuming and pointless process.

6/ BOM and coding line. These lines are there so that there is a higher
chance of tools (editors, compilers...) getting the source coding
correct. Without these lines, some tools will scan the complete file
checking that all chars >127 are part of a valid utf-8 sequence, some
will just make assumptions and possibly get it wrong.

7/ TYPViewer recognises strings in mapnik.txt as being encoded as utf8
regardless of the method used to open the file or BOM/coding line (good
- see above). On forcing a change to be saved, it converts to the
specified CodePage, quietly mapping chars not in this CodePage to their
more generic form.

8/ mkgmap TypCompiler does check for BOM. Up until January 2020, just in the 
utf8 encoding, but since then in 16LE/16BE/32LE/32BE as well, also looking for 
"-*- coding:" near the start of the file.

9/ Change mkgmap so that the message severity for missing numbers is downgraded 
for:
   ProductCode=
   FID=
as these will be generated from other sources

10/ as per your recent mail, TYPViewer does change the Type hex numbers
in the _draworder section

11/ utf8 should be the standard for all source files. You suggest it is
not needed for 99% of usage, but you are ruling out most countries of
the world. There is little extra effort required to support utf8 until
we meet tools like TYPViewer.

12/ "Correct procedure" - most of this is fine for you, but I'd suggest
always using TYPViewer in utf8/65001 mode and never using it to
generate the .typ file. Then in mkgmap, use your normal --code
-page=1252 because 65001 makes the map bigger and isn't supported on
many Garmin devices.

13/ Actual translations in mapnik.txt: this is an ongoing effort by
anyone who wants to improve it. In the spreadsheet you've highlighted
quite a few default strings - I don't see what is wrong with them; they
were specified as described in the posting:

http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2020q1/030254.html

You've also highlighted quite Dutch ones - could you do a patch for
these based on either the file I sent you or the latest svn source
file, or, failing that, just edit it and and sent it back to me.

Best wishes - hope everyone is healthy

Ticker


On Mon, 2020-03-30 at 21:59 +0200, eric_inter...@casema.nl wrote:
> Hi Ticker, Gerd,
> 
> I have spent "some" time in investigating "mapnik.txt" vs.
> "TypViewer".
> Understatement...
> 
> Things got out of hand...
> 
> Therefore: two attachments...
> 
> Best regards,
> 
> Eric (AnkEric)
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Errors converting "mapnik.txt" into "mapnik.typ" (information only)

[Ticker Berkin]

Hi Gerd

Yes, please commit.

I'm going to send another patch later for the mkgmap typ compiler and
it will include other changes to mapnik.txt so Eric, you might want to
hold off your testing until this is also committed.

Ticker
 
On Wed, 2020-04-01 at 01:35 -0700, AnkEric wrote:
> Hi Gerd,
> 
> This is not for me to decide. I'm just a User...
> 
> IMO: the mapnik-TYPViewer-2.patch is okay. So to be committed. IMO!
> 
> I will - again - verify (by TypViewer) if "mapnik.txt" is okay after
> committed patch.
> If not: I will let you know.
> 
> BTW: Did I gave you the impression I did understand???
> ROFL...
> I don't understand any of this, including my own document; -))
> 
> Eric
> 
> 
> 
> 
> 
> --
> Sent from: 
> http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Errors converting "mapnik.txt" into "mapnik.typ" (information only)

[Ticker Berkin]

Hi Gerd, Eric

Here is another patch to help TYPViewer users

- mkgmap TYP compiler skips [_comments] ... [End] sections

- for TYP lines in the [_id] section like:
  ProductCode=
  FID=
  CodePage=
ie. without a value, mkgmap now writes a WARN message to the log
instead of a SEVE: MapFailedException. These values will be supplied
from the main mkgmap --options anyway.

- put the mapnik.txt copyright message etc in the new [_comments] secti
on

- a few minor layout tweaks to mapnik.txt

Ticker
Index: resources/typ-files/mapnik.txt
===
--- resources/typ-files/mapnik.txt	(revision 4476)
+++ resources/typ-files/mapnik.txt	(working copy)
@@ -1,28 +1,33 @@
 ; TYP file to give mapnik rendering
 ; -*- coding: UTF-8 -*- NB: first 3 bytes/char in file is UTF-8 encoded ByteOrderMark (BOM)
-;
-;This program is free software; you can redistribute it and/or modify
-;it under the terms of the GNU General Public License version 3 or
-;version 2 as published by the Free Software Foundation.
-;
-;This program is distributed in the hope that it will be useful, but
-;WITHOUT ANY WARRANTY; without even the implied warranty of
-;MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
-;General Public License for more details.
-;
-;Author: jori...@hotmail.com
-;
-;Based on mkgmap default style version: r4293...4288
-;
+
+[_comments]
+This program is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License version 3 or
+version 2 as published by the Free Software Foundation.
+
+This program is distributed in the hope that it will be useful, but
+WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+General Public License for more details.
+
+Author: jori...@hotmail.com and others
+
+Based on mkgmap default style version: r4293
+[End]
+
+
 [_id]
 ;ProductCode=1   set from --product-id
 ;FID=8094set from --family-id
 ;CodePage=65001  set from --code-page
 [End]
-;
+
+
+;=== POLYGONS : RENDERING PRIORITY ==
 [_drawOrder]
+Type=0x03d,1
 Type=0x04b,1
-Type=0x03d,1
 Type=0x002,2
 Type=0x003,2
 Type=0x007,2
@@ -75,7 +80,11 @@
 Type=0x06c,8
 Type=0x004,9
 [End]
-;
+
+
+;= POLYGONS 
+
+
 [_polygon]
 type=0x02
 ;GRMN_TYPE: Urban Areas/SMALL_CITY/Small urban area, less than 200 000 inhabitants/Non NT
@@ -1184,7 +1193,11 @@
 Xpm="0 0 1 0"
 "1 c #BB"
 [end]
-;
+
+
+;== LINES ===
+
+
 [_line]
 type=0x01
 ;GRMN_TYPE: Roads/INTERSTATE, MAJOR_HWY/Primary, divided, limited-access highway, akin to an interstate in the US/Non NT, NT
@@ -2015,7 +2028,11 @@
 FontStyle=NoLabel (invisible)
 CustomColor=No
 [end]
-;
+
+
+;== POINTS ==
+
+
 [_point]
 type=0x001
 subtype=0x00
Index: src/uk/me/parabola/mkgmap/typ/IdSection.java
===
--- src/uk/me/parabola/mkgmap/typ/IdSection.java	(revision 4476)
+++ src/uk/me/parabola/mkgmap/typ/IdSection.java	(working copy)
@@ -13,6 +13,7 @@
 package uk.me.parabola.mkgmap.typ;
 
 import uk.me.parabola.imgfmt.app.typ.TypData;
+import uk.me.parabola.log.Logger;
 import uk.me.parabola.mkgmap.scan.SyntaxException;
 import uk.me.parabola.mkgmap.scan.TokenScanner;
 import uk.me.parabola.mkgmap.srt.SrtTextReader;
@@ -23,6 +24,8 @@
  * @author Steve Ratcliffe
  */
 class IdSection implements ProcessSection {
+	private static final Logger log = Logger.getLogger(IdSection.class);
+
 	private final TypData data;
 
 	public IdSection(TypData data) {
@@ -34,15 +37,25 @@
 		try {
 			ival = Integer.decode(value);
 		} catch (NumberFormatException e) {
-			throw new SyntaxException(scanner, "Bad integer " + value);
+			/* throw new SyntaxException(scanner, "Bad integer " + value);
+			 *
+			 * TYPViewer can leave these as:
+			 * FID=
+			 * ProductCode=
+			 * so just give a warning. Values will be supplied from mkgmap options.
+			 */
+			log.warn("bad/missing integer in TYP [_id] statement: ", name, "=", value);
+			ival = -1;
 		}
 
 		if (name.equalsIgnoreCase("FID")) {
-			data.setFamilyId(ival);
+			if (ival != -1)
+data.setFamilyId(ival);
 		} else if (name.equalsIgnoreCase("ProductCode")) {
-			data.setProductId(ival);
+			if (ival != -1)
+data.setProductId(ival);
 		} else if (name.equalsIgnoreCase("CodePage")) {
-			if (data.getSort() == null) // ignore if --code-page
+			if (ival != -1 && data.getSort() == null) // ignore if --code-page
 data.setSort(SrtTextReader.sortForCodepage(ival));
 		} else {
 			throw new SyntaxException(scanner, "Unrecognised keyword in id section: " + name);
Index: src/uk/me/parabola/mkgmap/typ/TypTextReader.java
===
--- src/uk/me/parabola/mkgmap/typ/TypTextReader.java	(revision 4476)
+++ src/uk/me/parabola/mkgma

Re: [mkgmap-dev] Blue background with Oregons, what whas the solution?

[Ticker Berkin]

Hi

The most significant information you need is which of the options:
  --precomp-sea=... --coastlinefile=... --generate-sea=...
are being used and their values. Also what version of mkgmap; there
have been a few changes in this area of the code in the last 4 months

Ticker

On Thu, 2020-04-02 at 13:31 +0200, Hans wrote:
> Hi Thorsten,
>  
> I own a pretty new Oregon 700 and a Montana 680. If you have an idea
> where (geographically) the blue area is, I can take over the testing.
>  
>  
> Herzliche Grüße
> Hans Straßgütl 
> Brunnenäckerweg 16
> D-72124 Pliezhausen   Phone:   
> Mobile:   
> Homepage: +49(0)7127-89453
> +49(0)171-3336559
> Motorradtouren.de
>  
> Am 2020-04-02 13:18, Thorsten Kukuk  schrieb:
> 
> Hi,
> 
> I'm pretty sure that I did read the discussion here, but cannot find
> it anywhere again.
> 
> On some Garmin devices (newer Oregons, e.g.) parts of the background
> of the map is shown as blue "sea", not with the normal background.
> Does anybody remember what the problem was and how to fix that?
> Since I don't own any of this devices who show it "wrong", I cannot
> test
> it myself.
> 
>  Thanks,
> Thorsten
> 
> -- 
> Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES &
> MicroOS
> SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg,
> Germany
> Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg)
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] How to make a scale-dependent TYP style?

[Ticker Berkin]

Hi

You'd have to do the same trick with all highway types and set a
representation for all of them in your TYP file

mkgmap doesn't have a default TYP, but there are a couple of examples
in {distribution}/examples/typ-files 

I find it best not to have any highway _lines in my personal TYP file
for the reasons you are seeing - it looks much better on my device to
let it represent them using its default mechanism.

Ticker

On Sat, 2020-04-04 at 19:55 +0200, Niccolo Rigacci wrote:
> On Sat, Apr 04, 2020 at 03:30:05PM +0200, Arndt Röhrig wrote:
> > 
> > you must create an own type for each zoom-level.
> > 
> > highway=motorway [0x1 resolution 24 continue]
> > highway=motorway [0x10101 resolution 23-20 continue]
> > highway=motorway [0x10102 resolution 19-18]
> 
> Thanks Arndt, this make sense!
> 
> But if I read the source file for the default style 
> (resources/styles/default/lines) I see only one definition for 
> (e.g.) highway=secondary:
> 
> highway=secondary [0x04 road_class=2 road_speed=3 resolution 20]
> 
> there are not other definitions for other resolutions! However 
> secondary roads are rendered with increasing sizes, starting from 
> resolution 20 to greather ones.
> 
> B.t.w. where can I find the default TYP file used by mkgmap?
> 
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] How to make a scale-dependent TYP style?

[Ticker Berkin]

Hi

Without an override from a TYP file, Garmin devices have their own,
inbuilt, rules about how to render each object (point/line/polygon) and
these vary from device to device, so no, there isn't and cannot be a
tool to do what you asked.

If you are making a map just for your particular device, the best thing
to do is generate a map without a TYP and see how it looks, then tweak
just the minimum with specific TYP [_xxx] entries.

For my eTrex HCx, not having a TYP works really well for points and
lines.

My eTrex 30x doesn't show some non-road lines, or shows them in white
which was almost impossible to see, so I have these in my TYP.

There are problems in the way they renders overlapping polygon and the
order in which they overwrite each other as the device is finding them,
but this is another topic.

For both, apart from the above, I much prefer their default rendering
rather than, say, {distribution}/examples/typ-files/mapnik.txt which
also slows down the devices to an almost unusable speed. 

Ticker

On Sat, 2020-04-04 at 21:24 +0200, Niccolo Rigacci wrote:
> On Sat, Apr 04, 2020 at 07:05:09PM +0100, Ticker Berkin wrote:
> > 
> > mkgmap doesn't have a default TYP, but there are a couple of
> > examples
> > in {distribution}/examples/typ-files 
> > 
> > I find it best not to have any highway _lines in my personal TYP
> > file
> > for the reasons you are seeing - it looks much better on my device
> > to
> > let it represent them using its default mechanism.
> 
> So, if I understand well what are you saying, the default 
> mechanism used by mkgmap is not based on TYP rules, but on 
> algorithmic procedures.
> 
> Is it possible to browse the native rendering types known by 
> mkgmap? Something like TYPViewer. So that I can use them instead 
> of creating new ones via TYP files.
> 
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] documentation improvement

[Ticker Berkin]

Hi

This explains an annoyance I've had with my newer eTrex 30x.

On the eTrex HCx, the map selection function uses the --family-name
value. The same map on the 30x just gave the name of one of the tiles,
which, now I look, was always the last.

Putting a final --description after the tile definitions now gives me
something that will work sensibly on both.

I'd like to request an enhancement that gmapSuppBuilder uses a new
option instead of --description.

Ticker

On Mon, 2020-04-06 at 15:04 +, Gerd Petermann wrote:
> Hi Mike,
> 
> will have a closer look tomorrow. Why do you think that  "putting -
> -description after -c template.args " is incorrect?
> When you use splitter with the --geonames-file option or with the -
> -description option the template.args file will set
> description.
> If you use both the --description option is ignored.
> The last given value for description is used for the combiners.
> 
> Gerd
> 
> 
> 
> Von: mkgmap-dev  im Auftrag
> von Mike Baggaley 
> Gesendet: Montag, 6. April 2020 16:46
> An: 'Development list for mkgmap'
> Betreff: [mkgmap-dev] documentation improvement
> 
> Hi Gerd, please find attached a small patch that improves the
> documentation
> primarily for the following, but with a few other minor tweaks:
> 
> removal of the statement about putting --description after -c
> template.args,
> as this incorrect
> simplification of the description of --style-file as this was
> confusing
> clarification that the number of bytes are the file sizes in the Hill
> Shading section
> 
> I note that the '' symbols used to denote arcseconds are being
> interpreted
> as italic identifiers  by whatever process produces the web
> page. I
> suggest this process needs to be changed so that this does not
> happen. I
> have replaced the first mentions of '' with words. If the process
> cannot
> easily be changed, I suggest that the remaining  '' symbols are
> replaced
> with arc second or arc seconds.
> 
> I also note that the --dem-dists mentions that values should be a
> multiple
> or submultiple of 3314 or 9942 then goes on to suggest values that
> are
> multiples of 3312, which I believe is the nearest value to 3314 that
> is a
> multiple of 16. I think the explanation needs some improvement by
> someone
> who knows exactly how it works. I have been experimenting with
> various
> values of --dem-dists - the default value of 9936 works fine for me
> at
> higher resolutions in Basecamp, but becomes very blocky at low
> resolution. I
> find --dem-dists=9936,9936,9936,9936,9936,9936,39744,317952 gives the
> best
> results for my levels of 0:24,1:22,2:21,3:20,4:19,5:18,6:17,7:15.
> Based on
> this, I'd be very surprised if the example in the documentation of
> --dem-dists=3312,13248,26512,53024 for levels 0:24, 1:22, 2:20, 3:18
> gives
> decent results at resolution 18. However, not having any 1 arc second
> DEM
> data, I can't try it.
> 
> Regards,
> Mike
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] documentation improvement

[Ticker Berkin]

Hi Gerd & Mike

@gerd - as you say, it is better to just improve the documentation of
what is there. As far as I could see it was only the tiles and gmapsupp
that took the --description.

I'd suggest changing from:

;--description=text
:   Set the descriptive text for the map. This may be displayed in
QLandkarte, MapSource or on a GPS, where it is normally shown
below the family name. Example: --description="Germany, Denmark"
Please note: if you use splitter to build a template.args file
and pass it to mkgmap, then that file may contain a "description"
that will override this option. To prevent splitter from overriding
your description, place the --description option
after "-c template.args".

to:

;--description=text
:   Set the descriptive text of map components.
Map tiles take the most recent --description before the --input-file
that defines the tile.
gmapsupp.img takes the last --description.
Note that the splitter generated template.args includes
relevant --description values (see splitter --geonames-file).
The usage of the component descriptions is not consistent between
GPS devices, MapSource, Basecamp and QLandkarte.
Some use the --family-name to enable the complete map, others use the
gmapsupp.img description.
Some devices can enable individual tiles using the tile description.
Suggested usage:
  ... -c options.cfg -c template.args --family-name=Scandinavia
  --description=Scandinavia --gmapsupp typFile.txt

@mike - if you & Gerd are happy with something like this, do you want
to put it into your patch, otherwise I'll do it once your option
changes are out of the way.

Ticker

On Tue, 2020-04-07 at 07:57 +, Gerd Petermann wrote:
> Hi Ticker,
> 
> I think this was discussed before and that discussion lead to the
> chapter about template.args. My suggestion would be to add a hint
> that the last given description is used by the combiners. I found
> usage in OverviewBuilder, TdbBuilder, and GmapsuppBuilder, not sure
> what the other combiners use. NsisBuilder and GmapiBuilder should be
> checked.
> I don't like the idea to introduce just another "description" option
> with unclear meaning, we already have so many.
> I also don't like the idea that we might break backward
> compatibility.
> 
> Gerd
> 
> 
> Von: mkgmap-dev  im Auftrag
> von Ticker Berkin 
> Gesendet: Montag, 6. April 2020 19:01
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] documentation improvement
> 
> Hi
> 
> This explains an annoyance I've had with my newer eTrex 30x.
> 
> On the eTrex HCx, the map selection function uses the --family-name
> value. The same map on the 30x just gave the name of one of the
> tiles,
> which, now I look, was always the last.
> 
> Putting a final --description after the tile definitions now gives me
> something that will work sensibly on both.
> 
> I'd like to request an enhancement that gmapSuppBuilder uses a new
> option instead of --description.
> 
> Ticker
> 
> On Mon, 2020-04-06 at 15:04 +, Gerd Petermann wrote:
> > Hi Mike,
> > 
> > will have a closer look tomorrow. Why do you think that  "putting -
> > -description after -c template.args " is incorrect?
> > When you use splitter with the --geonames-file option or with the -
> > -description option the template.args file will set
> > description.
> > If you use both the --description option is ignored.
> > The last given value for description is used for the combiners.
> > 
> > Gerd

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] missing check for option --family-id

[Ticker Berkin]

Hi Gerd

In the short term, warn if value < 0 or > 32767.

In the longer term, the methods in io/Structured{Input/Output}Stream
should be brought into line with the naming conventions in
imgfmt/app/*File{Reader/Writer} and the calls changed; the only
references are in imgfmt/mps and tdbfmt

Then tdb should be changed to consider this unsigned, store the vals as
an int, read/write with unsigned methods and change the warning range.

I'm happy to do the second set of changes sometime.

Ticker


On Tue, 2020-04-07 at 10:08 +, Gerd Petermann wrote:
> Hi all,
> in the garmin forum there is a discussion about the range :
> https://forum.openstreetmap.org/viewtopic.php?pid=782395#p782395
> 
> The current options.txt says 
> --family-id=integer
> This is an integer that identifies a family of products. Range:
> [1..]
> Default: 6324 
> 
> This limit is neither checked nor is it correct. The corresponding
> value is stored in a two byte field and most mkgmap sources interpret
> it as a 16-bit-unsigned integer.
> However, in class uk.me.parabola.tdbfmt.HeaderBlock the field is
> stored in a short (signed 16-bit-int). 
> 
> My conclusion: We should print a warning when the value given in -
> -family-id is < 0 or > 32767.
> 
> Gerd
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] documentation improvement

[Ticker Berkin]

Hi

I'll have a look and try and work out if the web version of options is
generated using the same software as the style manual, but, given there
are 2 unconnected processors being used to transform options.txt, I'd
recommend just replacing the '' with it spelt out.

The patch looks fine to me as well, but I'd have left in the bit about
tile selection by --description as this is the only usage of the tile
description that I've ever come across.

Ticker


On Wed, 2020-04-08 at 08:08 +, Gerd Petermann wrote:
> Hi Mike,
> 
> reg. 1 arc second or 1'' : I have no idea how to change the HTML
> creation process. My understanding is that we have to use some escape
> characters in options.txt and maybe some additional code in
> OptionsBuilder.java to remove those escape characters.
> @Ticker: Can you look at that?
> 
> Besides that the patch options3.txt.patch looks good to me.
> 
> Gerd
> 
> 
> 
> Von: mkgmap-dev  im Auftrag
> von Mike Baggaley 
> Gesendet: Mittwoch, 8. April 2020 09:40
> An: 'Development list for mkgmap'
> Betreff: Re: [mkgmap-dev] documentation improvement
> 
> Hi Gerd, please find an updated patch and another for the splitter
> documentation that describe the current operation.
> 
> It seems wrong to me for splitter to put the default description in a
> comment if --geonames-file is used without also specifying -
> -description.
> This means that a tile that cannot get a suitable value from the
> geonames
> file will end up getting the description of the preceding tile. I
> think that
> splitter should always output a description to the template.args file
> when
> --geonames-file is specified.
> 
> Regards,
> Mike
> 
> -Original Message-
> From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com]
> Sent: 08 April 2020 06:34
> To: 'Development list for mkgmap' 
> Subject: Re: [mkgmap-dev] documentation improvement
> 
> Hi Mike,
> 
> I've attached the template.args generated for this command:
> java -jar d:\splitter\dist\splitter.jar --description=test
> --max-nodes=10 --geonames-file=f:\osm\cities15000.zip
> f:\osm\bremen-latest.osm.pbf
> and
> java -jar d:\splitter\dist\splitter.jar --description=test
> --geonames-file=f:\osm\cities15000.zip  f:\osm\niedersachsen
> -latest.osm.pbf
> 
> Note that the one for Bremen is special because some tiles get the
> default
> description given with the --description option.
> 
> Gerd
> 
> 
> Von: mkgmap-dev  im Auftrag
> von Mike
> Baggaley 
> Gesendet: Mittwoch, 8. April 2020 00:55
> An: 'Development list for mkgmap'
> Betreff: Re: [mkgmap-dev] documentation improvement
> 
> Hi Gerd & Ticker,
> 
> Please find an updated patch that includes the essence of your
> comments on
> the --description option (I hope). Please let me know if you think
> further
> tweaks are needed.
> 
> Note, I'm not clear on the effect the splitter --geonames-file option
> has on
> the description. The splitter documentation only indicates it affects
> the
> file names of tiles. Does the splitter documentation need something
> adding?
> 
> There is still the question of whether the quote symbols need to be
> replaced
> with 'arc seconds' or whether the HTML creation process should be
> amended.
> 
> Also, clarification on the 3314/3312 values in --dem-dists.
> 
> Regards,
> Mike
> 
> -Original Message-
> From: Ticker Berkin [mailto:rwb-mkg...@jagit.co.uk]
> Sent: 07 April 2020 10:34
> To: Development list for mkgmap 
> Subject: Re: [mkgmap-dev] documentation improvement
> 
> Hi Gerd & Mike
> 
> @gerd - as you say, it is better to just improve the documentation of
> what is there. As far as I could see it was only the tiles and
> gmapsupp
> that took the --description.
> 
> I'd suggest changing from:
> 
> ;--description=text
> :   Set the descriptive text for the map. This may be displayed
> in
> QLandkarte, MapSource or on a GPS, where it is normally shown
> below the family name. Example: --description="Germany, Denmark"
> Please note: if you use splitter to build a template.args file
> and pass it to mkgmap, then that file may contain a "description"
> that will override this option. To prevent splitter from overriding
> your description, place the --description option
> after "-c template.args".
> 
> to:
> 
> ;--description=text
> :   Set the descriptive text of map components.
> Map tiles take the most recent --description before the --input-file
> that defines the

Re: [mkgmap-dev] How to make a scale-dependent TYP style?

[Ticker Berkin]

Hi Greg

For a long time, with my old eTrex HCx, all I used was:
- my style based on mkgmap-default
- the option  --order-by-decreasing-area
- TYP sameOrder.txt which is in the distribution, alongside mapnik.txt

Whenever I notice a problem, see a good idea or someone reports
difficulties that could be resolved by a style change, I tweak my
style, and, every now and again, I submit patches to the default style
that brings it closer to my version.

Recently I've been having to add a few _lines and _polygons to my TYP
because of differences between devices. I've also changed a few type
codes that make it incompatible with mkgmap-default & mapnik.txt, but I
plan to start a dialog on these as well.

Once the styles are compatible again, I'll look at submitting another
example typ-file.

I've attached my style and typ anyway, feel free to take whatever bits
you want.

Ticker 


On Tue, 2020-04-07 at 11:03 -0400, Greg Troxel wrote:
> Ticker Berkin  writes:
> 
> > For both, apart from the above, I much prefer their default
> > rendering
> > rather than, say, {distribution}/examples/typ-files/mapnik.txt
> > which
> > also slows down the devices to an almost unusable speed. 
> 
> Is your preferred approach part of mkgmap now?  I didn't find it
> alongside the mapnik typ, and I think it would be useful to share, as
> an
> example, or for use.  I have been using mkgmap for a very long time
> and
> concur that less is better.  I did use to use cferrero's typfile and
> style, which was mostly about adding stoplights and some other things
> not usually shown.   I'd like to see towers/masts as well, survey
> markers, and various other things that I'm not sure render without
> typ.
> 
> (I admit to being a little distant from what's going on as I mainly
> use
> OsmAnd, but I carry my etrex 30 as well, so I have two functioning
> devices in the woods.)
> 
> Thanks,
> Greg<>
;=== POLYGONS : RENDERING PRIORITY ==
[_drawOrder]
Type=0x01,2
Type=0x02,2
Type=0x03,2
Type=0x04,2
Type=0x05,2
Type=0x06,2
Type=0x07,2
Type=0x08,2
Type=0x09,2
Type=0x0a,2
Type=0x0b,2
Type=0x0c,2
Type=0x0d,2
Type=0x0e,2
Type=0x0f,2
Type=0x10,2
Type=0x11,2
Type=0x12,2
Type=0x13,2
Type=0x14,2
Type=0x15,2
Type=0x16,2
Type=0x17,2
Type=0x18,2
Type=0x19,2
Type=0x1a,2
Type=0x1b,2
Type=0x1c,2
Type=0x1d,2
Type=0x1e,2
Type=0x1f,2
Type=0x20,2
Type=0x21,2
Type=0x22,2
Type=0x23,2
Type=0x24,2
Type=0x25,2
Type=0x26,2
Type=0x27,2
Type=0x28,2
Type=0x29,2
Type=0x2a,2
Type=0x2b,2
Type=0x2c,2
Type=0x2d,2
Type=0x2e,2
Type=0x2f,2
Type=0x30,2
Type=0x31,2
Type=0x32,2
Type=0x33,2
Type=0x34,2
Type=0x35,2
Type=0x36,2
Type=0x37,2
Type=0x38,2
Type=0x39,2
Type=0x3a,2
Type=0x3b,2
Type=0x3c,2
Type=0x3d,2
Type=0x3e,2
Type=0x3f,2
Type=0x40,2
Type=0x41,2
Type=0x42,2
Type=0x43,2
Type=0x44,2
Type=0x45,2
Type=0x46,2
Type=0x47,2
Type=0x48,2
Type=0x49,2
Type=0x4a,2
Type=0x4b,2
Type=0x4c,2
Type=0x4d,2
Type=0x4e,2
Type=0x4f,2
Type=0x50,2
Type=0x51,2
Type=0x52,2
Type=0x53,2
Type=0x54,2
Type=0x55,2
Type=0x56,2
Type=0x57,2
Type=0x58,2
Type=0x59,2
Type=0x5a,2
Type=0x5b,2
Type=0x5c,2
Type=0x5d,2
Type=0x5e,2
Type=0x5f,2
[end]


;= POLYGONS 


[_polygon]
Type=0x02
;NA? think its better to have this as default/invisible as, unlike residential, 
doesn't disappear at high resolution
String=Suburb
Xpm="0 0 1 0"
"a c #FFE3E3"
[end]


[_polygon]
Type=0x03
String=Village
Xpm="0 0 1 0"
"a c #FFE3E3"
[end]


[_polygon]
Type=0x08
; String=Shopping Center
FontStyle=SmallFont
Xpm="0 0 1 0"
"a c #FF9966"
[end]


[_polygon]
Type=0x0f
String=Comme

Re: [mkgmap-dev] documentation improvement

[Ticker Berkin]

Hi Mike

I try to put in slight variants of the overall area description into:
 --family-name
 gmapsupp --description
 --series-name
and these occur in various places on devices and basecamp (--gmapi)
I set:
 --area-name
 --x-map-set-name
to variants of my name, and these also occur here and there.

My eTrex HCx allows me to disable/enable tiles within the gmapsupp on
an individual basis and this is the only use I've ever seen of the tile
description, which is why I think a mention of it should be left in

Ticker

On Wed, 2020-04-08 at 09:37 +0100, Mike Baggaley wrote:
> Hi Ticker, selection by description was mentioned to me by Gerd and
> explains something I'd noticed in BaseCamp. If I have the same map
> installed on my PC and on a memory card plugged into it, in the Maps
> menu I see "Great Britain" for the installed map and "Great Britain
> map" for the one on the card - I have --family-name="Great Britain"
> and --description="Great Britain map" in my command line.
> 
> Regards,
> Mike
> 
> -Original Message-
> From: Ticker Berkin [mailto:rwb-mkg...@jagit.co.uk] 
> Sent: 08 April 2020 09:25
> To: Development list for mkgmap 
> Subject: Re: [mkgmap-dev] documentation improvement
> 
> Hi
> 
> I'll have a look and try and work out if the web version of options
> is
> generated using the same software as the style manual, but, given
> there
> are 2 unconnected processors being used to transform options.txt, I'd
> recommend just replacing the '' with it spelt out.
> 
> The patch looks fine to me as well, but I'd have left in the bit
> about
> tile selection by --description as this is the only usage of the tile
> description that I've ever come across.
> 
> Ticker
> 
> 
> On Wed, 2020-04-08 at 08:08 +, Gerd Petermann wrote:
> > Hi Mike,
> > 
> > reg. 1 arc second or 1'' : I have no idea how to change the HTML
> > creation process. My understanding is that we have to use some
> > escape
> > characters in options.txt and maybe some additional code in
> > OptionsBuilder.java to remove those escape characters.
> > @Ticker: Can you look at that?
> > 
> > Besides that the patch options3.txt.patch looks good to me.
> > 
> > Gerd
> > 
> > 
> > 
> > Von: mkgmap-dev  im Auftrag
> > von Mike Baggaley 
> > Gesendet: Mittwoch, 8. April 2020 09:40
> > An: 'Development list for mkgmap'
> > Betreff: Re: [mkgmap-dev] documentation improvement
> > 
> > Hi Gerd, please find an updated patch and another for the splitter
> > documentation that describe the current operation.
> > 
> > It seems wrong to me for splitter to put the default description in
> > a
> > comment if --geonames-file is used without also specifying -
> > -description.
> > This means that a tile that cannot get a suitable value from the
> > geonames
> > file will end up getting the description of the preceding tile. I
> > think that
> > splitter should always output a description to the template.args
> > file
> > when
> > --geonames-file is specified.
> > 
> > Regards,
> > Mike
> > 
> > -Original Message-
> > From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com]
> > Sent: 08 April 2020 06:34
> > To: 'Development list for mkgmap' 
> > Subject: Re: [mkgmap-dev] documentation improvement
> > 
> > Hi Mike,
> > 
> > I've attached the template.args generated for this command:
> > java -jar d:\splitter\dist\splitter.jar --description=test
> > --max-nodes=10 --geonames-file=f:\osm\cities15000.zip
> > f:\osm\bremen-latest.osm.pbf
> > and
> > java -jar d:\splitter\dist\splitter.jar --description=test
> > --geonames-file=f:\osm\cities15000.zip  f:\osm\niedersachsen
> > -latest.osm.pbf
> > 
> > Note that the one for Bremen is special because some tiles get the
> > default
> > description given with the --description option.
> > 
> > Gerd
> > 
> > 
> > Von: mkgmap-dev  im Auftrag
> > von Mike
> > Baggaley 
> > Gesendet: Mittwoch, 8. April 2020 00:55
> > An: 'Development list for mkgmap'
> > Betreff: Re: [mkgmap-dev] documentation improvement
> > 
> > Hi Gerd & Ticker,
> > 
> > Please find an updated patch that includes the essence of your
> > comments on
> > the --description option (I hope). Please let me know if you think
> > further
> > tweaks are needed.
> >

Re: [mkgmap-dev] splitter and options --description / --geonames-file

[Ticker Berkin]

Hi Gerd

I'd say that if the splitter is going to generate descriptions per tile
(geonames) it should generate one for each tile and, if there isn't a
centre of a city within the tile and no default description, it should
use a modified form of the nearest city to make it unique from a
possible adjacent tile that might use the same city.

Maybe something like "GB-~Basingstoke", but no solution is ideal and
there could still be duplicates.

The splitter could keep track of which names were have been used and,
for the ones outside the tile, added an increasing suffix number, so
would have "GB-Basingstoke-2" etc

Ticker

On Wed, 2020-04-08 at 08:38 +, Gerd Petermann wrote:
> Hi all,
> 
> this is a follow up of http://gis.19327.n8.nabble.com/documentation-i
> mprovement-tp5962609p5962747.html
> 
> Since I don't use these options for my maps I am unsure what is best.
> The --geonames-file option tries to find a city within the calculated
> tile. If none is found it either writes the value
> given with --description or just a comment.
> I think it would be best to always write the nearest city.
> 
> Gerd
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Default Style - dead conditions?

[Ticker Berkin]

Hi Nick

The second occurrence of all of these is in the

section so no problem, the rules get triggered.

Ticker
 

On Wed, 2020-04-08 at 04:03 -0700, nwillink wrote:
> Hi Ticker 
> 
> Looking at you style file I noticed that there might be an issue 
>  with the
> following
> 
> (In fact it is found in the default style)
> 
> 145   highway=motorway [0x01 road_class=4 road_speed=7
> resolution 15]
> 277   (highway=motorway | highway=trunk)  & ref=*{name
> '${ref|highway-symbol:hbox}'; addlabel '${name}'}
> 
> Under which condition will  highway=motorway be TRUE in line 277
> 
> Are we missing a 'continue' ? 
> ie
> 
> highway=motorway [0x01 road_class=4 road_speed=7 resolution 15
> continue]
> 
> (Same applies for primary& secondary)
>  
> 155   highway=primary [0x03 road_class=3 road_speed=4 resolution
> 19]
> 278   highway=primary  & ref=*{name '${ref|highway
> -symbol:box}' ; addlabel
> '${name}'}
>  
>   161 highway=secondary [0x04 road_class=2 road_speed=3
> resolution 20]
> 279   (highway=secondary | highway=tertiary) & ref=*{name
> '${ref|highway-symbol:oval}'; addlabel '${name}'}
> 
> Regards
> 
> Nick
>  
> 
> 
> 
> --
> Sent from: 
> http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] documentation improvement

[Ticker Berkin]

Hi Mike

Yes, that's fine

Ticker

On Wed, 2020-04-08 at 13:08 +0100, Mike Baggaley wrote:
> Hi Ticker, sorry, I misread your previous email - I thought you were
> suggesting it should have been left out - I had included "Different
> GPS devices, MapSource, Basecamp and QLandkarte handle descriptions
> inconsistently. Some display the description when selecting maps,
> others use the family name" and thought this covered the point.
> However, I now realise you were referring to selection of tiles. I've
> added "or tiles" after "when selecting maps", and also replaced the
> arc second symbols. Is that better?
> 
> Cheers,
> Mike
> 
> 
> 
> -Original Message-
> From: Ticker Berkin [mailto:rwb-mkg...@jagit.co.uk] 
> Sent: 08 April 2020 09:55
> To: Development list for mkgmap 
> Subject: Re: [mkgmap-dev] documentation improvement
> 
> Hi Mike
> 
> I try to put in slight variants of the overall area description into:
>  --family-name
>  gmapsupp --description
>  --series-name
> and these occur in various places on devices and basecamp (--gmapi)
> I set:
>  --area-name
>  --x-map-set-name
> to variants of my name, and these also occur here and there.
> 
> My eTrex HCx allows me to disable/enable tiles within the gmapsupp on
> an individual basis and this is the only use I've ever seen of the
> tile
> description, which is why I think a mention of it should be left in
> 
> Ticker
> 
> On Wed, 2020-04-08 at 09:37 +0100, Mike Baggaley wrote:
> > Hi Ticker, selection by description was mentioned to me by Gerd and
> > explains something I'd noticed in BaseCamp. If I have the same map
> > installed on my PC and on a memory card plugged into it, in the
> > Maps
> > menu I see "Great Britain" for the installed map and "Great Britain
> > map" for the one on the card - I have --family-name="Great Britain"
> > and --description="Great Britain map" in my command line.
> > 
> > Regards,
> > Mike
> > 
> > -Original Message-
> > From: Ticker Berkin [mailto:rwb-mkg...@jagit.co.uk] 
> > Sent: 08 April 2020 09:25
> > To: Development list for mkgmap 
> > Subject: Re: [mkgmap-dev] documentation improvement
> > 
> > Hi
> > 
> > I'll have a look and try and work out if the web version of options
> > is
> > generated using the same software as the style manual, but, given
> > there
> > are 2 unconnected processors being used to transform options.txt,
> > I'd
> > recommend just replacing the '' with it spelt out.
> > 
> > The patch looks fine to me as well, but I'd have left in the bit
> > about
> > tile selection by --description as this is the only usage of the
> > tile
> > description that I've ever come across.
> > 
> > Ticker
> > 
> > 
> > On Wed, 2020-04-08 at 08:08 +, Gerd Petermann wrote:
> > > Hi Mike,
> > > 
> > > reg. 1 arc second or 1'' : I have no idea how to change the HTML
> > > creation process. My understanding is that we have to use some
> > > escape
> > > characters in options.txt and maybe some additional code in
> > > OptionsBuilder.java to remove those escape characters.
> > > @Ticker: Can you look at that?
> > > 
> > > Besides that the patch options3.txt.patch looks good to me.
> > > 
> > > Gerd

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] documentation improvement

[Ticker Berkin]

Hi

I can't work out what tools are being used to transform options.txt
into the inner contents of http://www.mkgmap.org.uk/doc/options 

It doesn't seem to be asciidoc, as used by the style manual.

Ticker

On Wed, 2020-04-08 at 09:25 +0100, Ticker Berkin wrote:
> Hi
> 
> I'll have a look and try and work out if the web version of options
> is
> generated using the same software as the style manual, but, given
> there
> are 2 unconnected processors being used to transform options.txt, I'd
> recommend just replacing the '' with it spelt out.
> 
> The patch looks fine to me as well, but I'd have left in the bit
> about
> tile selection by --description as this is the only usage of the tile
> description that I've ever come across.
> 
> Ticker

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] documentation improvement

[Ticker Berkin]

Hi Gerd

It isn't this - this code puts in some html tags/classes that don't
appear on the web page

I suspect nothing in ./scripts/ is used any more

Ticker


On Wed, 2020-04-08 at 17:02 +, Gerd Petermann wrote:
> Is it mkgmap\scripts\options_to_doc.py ?
> 
> 
> 
> Von: mkgmap-dev  im Auftrag
> von Ticker Berkin 
> Gesendet: Mittwoch, 8. April 2020 18:58
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] documentation improvement
> 
> Hi
> 
> I can't work out what tools are being used to transform options.txt
> into the inner contents of http://www.mkgmap.org.uk/doc/options
> 
> It doesn't seem to be asciidoc, as used by the style manual.
> 
> Ticker
> 
> On Wed, 2020-04-08 at 09:25 +0100, Ticker Berkin wrote:
> > Hi
> > 
> > I'll have a look and try and work out if the web version of options
> > is
> > generated using the same software as the style manual, but, given
> > there
> > are 2 unconnected processors being used to transform options.txt,
> > I'd
> > recommend just replacing the '' with it spelt out.
> > 
> > The patch looks fine to me as well, but I'd have left in the bit
> > about
> > tile selection by --description as this is the only usage of the
> > tile
> > description that I've ever come across.
> > 
> > Ticker
> 
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] splitter and options --description / --geonames-file

[Ticker Berkin]

Hi

I'd go for the idea of having the specific option eg --add-google-plus.

Also, as a slight modification to the patch that increases the area
beyond the tile looking for a city, maybe limit it double the tile size
before giving up and just describing the tile with the mapName.

Ticker

On Fri, 2020-04-10 at 06:46 +, Gerd Petermann wrote:
> Hi Randolph,
> 
> when I want to visualize the calulcated areas I use --write
> -kml=splitter.kml. The output file splitter.kml can be used in JOSM
> (with a plugin) as well as in Google Earth,
> if you prefer that. The use in JOSM helps me to find issues where a
> tile border might be involved.
> 
> Anyhow, if others are interested I would use your patch with a
> different option, something like --add-google-plus which would either
> add the code to the city name or to the given description or to an
> empty string so that splitter would always generate a unique tile
> description.
> 
> Gerd
> 
> 
> 
> Von: Randolph J. Herber 
> Gesendet: Freitag, 10. April 2020 02:17
> An: Development list for mkgmap; Gerd Petermann; Mike Baggaley;
> Ticker Berkin
> Betreff: Re: [mkgmap-dev] splitter and options --description / -
> -geonames-file
> 
> Hi, all!
> 
> Yes, it helps.
> 
> It was not what I had in mind.
> 
> [Fragment of  template.args showing the OLC or Google Plus
> Codes that were  added.]
> 
> These codes can be directly used to show the area in question: EG
> -Alexandria:8G3F5W00+<https://plus.codes/8G3F5W00+>
> 
> [Image of  Alexandria, Egypt, area referenced.]
> 
> and for an Egyptian area with no cities with a population as large as
> 15 000: EgyptUC:7GJM+<https://plus.codes/7GJM+>
> 
> [Large area insouthern Egypt with no cities as large as 15
> thousand people.]
> 
> This area is in southern Egypt.
> 
> The differences in AreaList.java, in Unix format are in the attached
> differences file.
> 
> The modified AreaList.java files in the attached java file.
> 
> Can you now understand what I want and why?
> 
> Randolph J. Herber
> 
> 
> On 4/9/2020 9:48 AM, Gerd Petermann wrote:
> 
> Hi all,
> 
> sorry, I think some mails where not sent to the list. I've attached a
> patch that adds a number to the city name when --geonames-file is
> used and multiple tiles
> are close to that city.
> 
> I fear I don't know in what situation these names are important. So,
> please try if this improves something.
> 
> Gerd

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] POI barrier/access restriction

[Ticker Berkin]

Hi Gerd and others interested in routing issues

default style "points" has code that, when option --link-pois-to-ways
is in effect, sets highway access and speed restrictions that mkgmap
then imposes on the highway that the point is on.

These rules had various errors:
- didn't expand the access mode hierarchy, see
  https://wiki.openstreetmap.org/wiki/Key:access
- tested the wrong tag for mkgmap:bus and mkgmap:delivery
- if the "access" tag was set, apply this to all modes before
  processing allowances and restrictions imposed by the
  barrier; but these actions would have no effect because the
  the specified mode tags are now all set
- assumed that a gate stops motor_vehicle access
- didn't handle other common forms of gate
- allowed bicycle through kissing_gate and stile

This patch fixes these problems and also adds a speed restriction for
all barriers.

The general principle is that barrier rules add specific "no"
restrictions that the barrier prevents, but must not add "yes".
The "access" tag is a default for all modes not implicitly or explicit
handled; there could be, say, osm tags [barrier=stile,
access=destination] and this should not imply there is unrestricted
foot access.

Ticker
Index: resources/styles/default/points
===
--- resources/styles/default/points	(revision 4480)
+++ resources/styles/default/points	(working copy)
@@ -10,40 +10,62 @@
 
 addr:housenumber=* {set mkgmap:execute_finalize_rules=true}
 
+# impose routing/speed restrictions due to access/barrier. See option --link-pois-to-ways
+
+vehicle=* {
+add bicycle='${vehicle}';
+add motor_vehicle='${vehicle}';
+}
+motor_vehicle=* {
+add motorcar='${motor_vehicle}';
+add goods='${motor_vehicle}';
+add hgv='${motor_vehicle}';
+add psv='${motor_vehicle}';
+add emergency='${motor_vehicle}';
+}
+psv=* {
+add taxi='${psv}';
+add bus='${psv}';
+}
+
 barrier=* & bicycle=*   {set mkgmap:bicycle  =  '${bicycle|subst:private=>no}'}
 barrier=* & foot=*  {set mkgmap:foot = '${foot|subst:private=>no}'}
 barrier=* & hgv=*   {set mkgmap:truck=  '${hgv|subst:private=>no}'}
 barrier=* & motorcar=*  {set mkgmap:car  = '${motorcar|subst:private=>no}'}
-barrier=* & psv=*   {set mkgmap:bus  =  '${psv|subst:private=>no}'}
+barrier=* & bus=*   {set mkgmap:bus  =  '${bus|subst:private=>no}'}
 barrier=* & taxi=*  {set mkgmap:taxi = '${taxi|subst:private=>no}'}
 barrier=* & emergency=* {set mkgmap:emergency='${emergency|subst:private=>no}'}
-barrier=* & delivery=*  {set mkgmap:delivery = '${delivery|subst:private=>no}'}
-barrier=* & access=*{addaccess   '${access|subst:private=>no}'}
+barrier=* & goods=* {set mkgmap:delivery ='${goods|subst:private=>no}'}
 
-barrier=bollard | barrier=cycle_barrier {
-add mkgmap:bicycle=yes;
-add mkgmap:foot=yes;
-addaccess no;
-set mkgmap:road-speed=1;
+barrier=bollard | barrier=block {
+add mkgmap:car=no;
+add mkgmap:delivery=no;
+add mkgmap:truck=no;
+add mkgmap:bus=no;
+add mkgmap:taxi=no;
+add mkgmap:emergency=no;
 }
+barrier=cycle_barrier | barrier=kissing_gate | barrier=stile {
+add mkgmap:bicycle=no;
+add mkgmap:car=no;
+add mkgmap:delivery=no;
+add mkgmap:truck=no;
+add mkgmap:bus=no;
+add mkgmap:taxi=no;
+add mkgmap:emergency=no;
+set mkgmap:road-speed=0;
+}
 barrier=bus_trap {
-add mkgmap:bus=yes;
-add mkgmap:foot=yes;
-add mkgmap:bicycle=yes;
-addaccess no;
-set mkgmap:road-speed=1;
+add mkgmap:car=no;
+add mkgmap:delivery=no;
+add mkgmap:truck=no;
+add mkgmap:taxi=no;
 }
-barrier=gate {
-add mkgmap:bicycle=yes;
-add mkgmap:foot=yes;
-addaccess no;
+barrier=gate | barrier=lift_gate | barrier=swing_gate {
 set mkgmap:road-speed=0;
 }
-barrier=kissing_gate | barrier=stile | barrier=block {
-add mkgmap:foot=yes;
-addaccess no;
-set mkgmap:road-speed=0;
-}
+barrier=* {add mkgmap:road-speed=1}
+barrier=* & access=* {addaccess '${access|subst:private=>no}'}
 
 internet_access=yes {name 'Internet ${name}' | 'Internet'} [0x2f12 resolution 24 continue]
 internet_access=* & internet_access!=no & internet_access!=yes
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] POI barrier/access restriction

[Ticker Berkin]

Hi Gerd

The only common bit is filling in the mode hierarchy. It could be moved
into an include and shared, but it is only 15 lines.

Ticker

On Mon, 2020-04-13 at 11:31 +, Gerd Petermann wrote:
> Hi Ticker,
> 
> did not check the details yet but the patch seems to duplicate a lot
> of stuff coded in inc/access. Is that needed?
> 
> Gerd
> 
> 
> Von: mkgmap-dev  im Auftrag
> von Ticker Berkin 
> Gesendet: Montag, 13. April 2020 13:21
> An: mkgmap development
> Betreff: [mkgmap-dev] POI barrier/access restriction
> 
> Hi Gerd and others interested in routing issues
> 
> default style "points" has code that, when option --link-pois-to-ways
> is in effect, sets highway access and speed restrictions that mkgmap
> then imposes on the highway that the point is on.
> 
> These rules had various errors:
> - didn't expand the access mode hierarchy, see
>   https://wiki.openstreetmap.org/wiki/Key:access
> - tested the wrong tag for mkgmap:bus and mkgmap:delivery
> - if the "access" tag was set, apply this to all modes before
>   processing allowances and restrictions imposed by the
>   barrier; but these actions would have no effect because the
>   the specified mode tags are now all set
> - assumed that a gate stops motor_vehicle access
> - didn't handle other common forms of gate
> - allowed bicycle through kissing_gate and stile
> 
> This patch fixes these problems and also adds a speed restriction for
> all barriers.
> 
> The general principle is that barrier rules add specific "no"
> restrictions that the barrier prevents, but must not add "yes".
> The "access" tag is a default for all modes not implicitly or
> explicit
> handled; there could be, say, osm tags [barrier=stile,
> access=destination] and this should not imply there is unrestricted
> foot access.
> 
> Ticker
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] options.txt improvements

[Ticker Berkin]

Hi Gerd

Some improvements to options.txt:
- layout and spacing
- gmapi and family-name
- generate-sea options

Ticker
Index: doc/options.txt
===
--- doc/options.txt	(revision 4480)
+++ doc/options.txt	(working copy)
@@ -67,8 +67,11 @@
 then they are compiled first and then the gmapsupp is created.
 
 ;--gmapi
-: 	Create a directory in the "gmapi" format required by Mac applications. Can
-also be used for Windows programs.
+: 	Create a directory in the "gmapi" format required by Mac applications.
+It can also be used for Windows programs; copy the complete directory tree into
+{user}\AppData\Roaming\Garmin\Maps or \ProgramData\Garmin\Maps
+and the map will be available in BaseCamp.
+The directory name is --family-name with extension .gmap.
 
 ;-c filename
 ;--read-config=filename
@@ -408,8 +411,8 @@
 : 	If you build several maps, this option describes the
 family name of all of your maps. Garmin will display this
 in the map selection screen.
-
-Example: --family-name="OpenStreetmap mkgmap XL 2019"
+The default is "OSM map".
+:	Example: --family-name="OpenStreetmap mkgmap XL 2019"
 
 ;--product-id=integer
 : 	This is an integer that identifies a product within a family.
@@ -738,51 +741,44 @@
 this option is set. Files must have OSM or PBF file format.	
 
 ;--generate-sea[=ValueList]
-: 	Generate sea polygons. ValueList is an optional comma
-separated list of values:
-
+:	Generate sea polygons. ValueList is a comma separated list of values:
 :;multipolygon
 :: generate the sea using a multipolygon (the default behaviour so this really doesn't need to be specified).
-
 :;polygons | no-mp
 :: don't generate the sea using a multipolygon - instead,
 generate a background sea polygon plus individual land
-polygons with tag natural=land. This requires a
-suitable land polygon type to be defined in the style
-file (suggested type is 0x010100) and the polygon must
-be defined in the TYP file as having a higher drawing
-level than the sea polygon type.
-
+polygons with land-tag (see following).
 :;no-sea-sectors
 :: disable the generation of "sea sectors" when the
 coastline fails to reach the tile's boundary.
+Under some conditions land sectors are generated instead and these use land-tag.
 :;extend-sea-sectors
-:: same as no-sea-sectors. Additional adds a point so coastline reaches the nearest tile boundary.
-
+:: Adds a point so coastline reaches the nearest tile boundary.
+This implies no-sea-sectors.
 :;land-tag=TAG=VAL
 :: tag to use for land polygons (default natural=land).
+If not using "multipolygon" or land sectors are being generated, then
+a suitable land polygon type needs to be defined in the style
+file (suggested type is 0x010100 or 0x54) and the polygon must
+be defined in the TYP file as having a higher drawing
+level than the sea polygon type.
 :;close-gaps=NUM
 :: close gaps in coastline that are less than this distance (metres)
-
 :;floodblocker
 :: enable the flood blocker that prevents a flooding of
 land by checking if the sea polygons contain streets
 (works only with multipolygon processing)		
-
 :;fbgap=NUM
 :: flood blocker gap in metre (default 40)
 points that are closer to the sea polygon do not block
-
 :;fbthres=NUM
 :: at least so many highway points must be contained in
 a sea polygon so that it may be removed by the flood
 blocker (default 20)
-
 :;fbratio=NUM
 :: only sea polygons with a higher ratio
 (highway points * 10 / polygon size) are removed
 (default 0.5)
-
 :;fbdebug
 :: switches on the debugging of the flood blocker
 generates GPX files for each polygon checked by
Index: resources/help/en/options
===
--- resources/help/en/options	(revision 4480)
+++ resources/help/en/options	(working copy)
@@ -65,8 +65,11 @@
 the gmapsupp is created.
 
 --gmapi
-Create a directory in the "gmapi" format required by Mac applications. Can
-also be used for Windows programs.
+Create a directory in the "gmapi" format required by Mac applications. It
+can also be used for Windows programs; copy the complete directory tree
+into {user}\AppData\Roaming\Garmin\Maps or \ProgramData\Garmin\Maps and the
+map will be available in BaseCamp. The directory name is --family-name with
+extension .gmap.
 
 -c filename
 --read-config=filename
@@ -395,10 +398,10 @@
 
 --family-name=name
 If you build several maps, this option describes the family name of all of
-your maps. Garmin will display this in the map selection screen.
+your maps. Garmin will display this in the map selection screen. The
+default is "OSM map".
+Example: --family-name="OpenStreetmap mkgmap XL 2019"
 
- Example: --family-name="OpenStreetmap mkgmap XL 2019"
-
 --product-id=integer
 This is an integer that identifies a product within a family. It is often
 just 1, which is the default.
@@ -722,50 +725,42 @@
 must have OSM or PBF file format

Re: [mkgmap-dev] POI barrier/access restriction

[Ticker Berkin]

Hi Gerd

I agree that OSM mappers don't always put the correct access rights on
barriers, but often they do, and if wrong it can be corrected. I'm not
sure what you mean by "hard to say what defaults should be used"?

I consider that this patch corrects flaws as I listed in the interpreta
tion of OSM data relating to barriers and handles some more common
barrier types.

A couple of the fixes relate to transport modes I don't use (goods/psv)
but the error and fix is textually obvious.

Others relate to combinations like [barrier=gate, vehicle=no], because
vehicle is not expanded to bicycle, motorcar, etc. 

A common problems I had was failure to route by car through a gate.

Another problem is [barrier={"bollard" etc}, access={anything but "no"
or "private"], that would fail to impose a restriction on car, or,
indeed, any motor_vehicle

Ticker

On Tue, 2020-04-14 at 13:07 +, Gerd Petermann wrote:
> Hi Ticker,
> 
> it is difficult to find good rules for barriers Many people don't map
> the access rights and thus it is hard to say what defaults should be
> used.
> At least that was the case when I changed the rules in 2013 ;)
> 
> In what situations do you see improvements with your patch?
> 
> Gerd
> 
> 
> Von: mkgmap-dev  im Auftrag
> von Ticker Berkin 
> Gesendet: Montag, 13. April 2020 15:04
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] POI barrier/access restriction
> 
> Hi Gerd
> 
> The only common bit is filling in the mode hierarchy. It could be
> moved
> into an include and shared, but it is only 15 lines.
> 
> Ticker
> 
> On Mon, 2020-04-13 at 11:31 +, Gerd Petermann wrote:
> > Hi Ticker,
> > 
> > did not check the details yet but the patch seems to duplicate a
> > lot
> > of stuff coded in inc/access. Is that needed?
> > 
> > Gerd
> > 
> > 
> > Von: mkgmap-dev  im Auftrag
> > von Ticker Berkin 
> > Gesendet: Montag, 13. April 2020 13:21
> > An: mkgmap development
> > Betreff: [mkgmap-dev] POI barrier/access restriction
> > 
> > Hi Gerd and others interested in routing issues
> > 
> > default style "points" has code that, when option --link-pois-to
> > -ways
> > is in effect, sets highway access and speed restrictions that
> > mkgmap
> > then imposes on the highway that the point is on.
> > 
> > These rules had various errors:
> > - didn't expand the access mode hierarchy, see
> >   https://wiki.openstreetmap.org/wiki/Key:access
> > - tested the wrong tag for mkgmap:bus and mkgmap:delivery
> > - if the "access" tag was set, apply this to all modes before
> >   processing allowances and restrictions imposed by the
> >   barrier; but these actions would have no effect because the
> >   the specified mode tags are now all set
> > - assumed that a gate stops motor_vehicle access
> > - didn't handle other common forms of gate
> > - allowed bicycle through kissing_gate and stile
> > 
> > This patch fixes these problems and also adds a speed restriction
> > for
> > all barriers.
> > 
> > The general principle is that barrier rules add specific "no"
> > restrictions that the barrier prevents, but must not add "yes".
> > The "access" tag is a default for all modes not implicitly or
> > explicit
> > handled; there could be, say, osm tags [barrier=stile,
> > access=destination] and this should not imply there is unrestricted
> > foot access.
> > 
> > Ticker
> > ___
> > mkgmap-dev mailing list
> > mkgmap-dev@lists.mkgmap.org.uk
> > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] POI barrier/access restriction

[Ticker Berkin]

Hi Gerd

Here is one, [barrier=gate] on [highway=unclassified]

https://www.openstreetmap.org/node/1394202186

Ticker

On Wed, 2020-04-15 at 08:13 +, Gerd Petermann wrote:
> Hi Ticker,
> 
> I think the patch looks good, I hoped for some samples where a
> correctly mapped barrier on a correctly mapped way shows problems
> with the existing rules ,e.g. "failure to route by car through a
> gate".
> 
> Gerd
> 
> ____
> Von: mkgmap-dev  im Auftrag
> von Ticker Berkin 
> Gesendet: Mittwoch, 15. April 2020 10:07
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] POI barrier/access restriction
> 
> Hi Gerd
> 
> I agree that OSM mappers don't always put the correct access rights
> on
> barriers, but often they do, and if wrong it can be corrected. I'm
> not
> sure what you mean by "hard to say what defaults should be used"?
> 
> I consider that this patch corrects flaws as I listed in the
> interpreta
> tion of OSM data relating to barriers and handles some more common
> barrier types.
> 
> A couple of the fixes relate to transport modes I don't use
> (goods/psv)
> but the error and fix is textually obvious.
> 
> Others relate to combinations like [barrier=gate, vehicle=no],
> because
> vehicle is not expanded to bicycle, motorcar, etc.
> 
> A common problems I had was failure to route by car through a gate.
> 
> Another problem is [barrier={"bollard" etc}, access={anything but
> "no"
> or "private"], that would fail to impose a restriction on car, or,
> indeed, any motor_vehicle
> 
> Ticker
> 
> On Tue, 2020-04-14 at 13:07 +, Gerd Petermann wrote:
> > Hi Ticker,
> > 
> > it is difficult to find good rules for barriers Many people don't
> > map
> > the access rights and thus it is hard to say what defaults should
> > be
> > used.
> > At least that was the case when I changed the rules in 2013 ;)
> > 
> > In what situations do you see improvements with your patch?
> > 
> > Gerd
> > 
> > 
> > Von: mkgmap-dev  im Auftrag
> > von Ticker Berkin 
> > Gesendet: Montag, 13. April 2020 15:04
> > An: Development list for mkgmap
> > Betreff: Re: [mkgmap-dev] POI barrier/access restriction
> > 
> > Hi Gerd
> > 
> > The only common bit is filling in the mode hierarchy. It could be
> > moved
> > into an include and shared, but it is only 15 lines.
> > 
> > Ticker
> > 
> > On Mon, 2020-04-13 at 11:31 +, Gerd Petermann wrote:
> > > Hi Ticker,
> > > 
> > > did not check the details yet but the patch seems to duplicate a
> > > lot
> > > of stuff coded in inc/access. Is that needed?
> > > 
> > > Gerd
> > > 
> > > 
> > > Von: mkgmap-dev  im
> > > Auftrag
> > > von Ticker Berkin 
> > > Gesendet: Montag, 13. April 2020 13:21
> > > An: mkgmap development
> > > Betreff: [mkgmap-dev] POI barrier/access restriction
> > > 
> > > Hi Gerd and others interested in routing issues
> > > 
> > > default style "points" has code that, when option --link-pois-to
> > > -ways
> > > is in effect, sets highway access and speed restrictions that
> > > mkgmap
> > > then imposes on the highway that the point is on.
> > > 
> > > These rules had various errors:
> > > - didn't expand the access mode hierarchy, see
> > >   https://wiki.openstreetmap.org/wiki/Key:access
> > > - tested the wrong tag for mkgmap:bus and mkgmap:delivery
> > > - if the "access" tag was set, apply this to all modes before
> > >   processing allowances and restrictions imposed by the
> > >   barrier; but these actions would have no effect because the
> > >   the specified mode tags are now all set
> > > - assumed that a gate stops motor_vehicle access
> > > - didn't handle other common forms of gate
> > > - allowed bicycle through kissing_gate and stile
> > > 
> > > This patch fixes these problems and also adds a speed restriction
> > > for
> > > all barriers.
> > > 
> > > The general principle is that barrier rules add specific "no"
> > > restrictions that the barrier prevents, but must not add "yes".
> > > The "access" tag is a default for all modes not implicitly or
> > > explicit
> > > handled; th

Re: [mkgmap-dev] POI barrier/access restriction

[Ticker Berkin]

Hi Gerd

For gate/lift_gate/swing_gate the new rules don't make any access
assumptions, but any access/mode tags will be respected.

eg [barrier=gate, foot=yes, access=private] will set mkgmap:foot=yes
and all the others to "no"

[barrier=swing_gate] would just imposes the speed penalty.

Ticker

On Wed, 2020-04-15 at 08:39 +, Gerd Petermann wrote:
> Hi Ticker,
> 
> what are your assumptions reg. default access for a barrier=gate?
> 
> Gerd
> 
> 
> Von: mkgmap-dev  im Auftrag
> von Ticker Berkin 
> Gesendet: Mittwoch, 15. April 2020 10:35
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] POI barrier/access restriction
> 
> Hi Gerd
> 
> Here is one, [barrier=gate] on [highway=unclassified]
> 
> https://www.openstreetmap.org/node/1394202186
> 
> Ticker
> 
> On Wed, 2020-04-15 at 08:13 +, Gerd Petermann wrote:
> > Hi Ticker,
> > 
> > I think the patch looks good, I hoped for some samples where a
> > correctly mapped barrier on a correctly mapped way shows problems
> > with the existing rules ,e.g. "failure to route by car through a
> > gate".
> > 
> > Gerd
> > 
> > 
> > Von: mkgmap-dev  im Auftrag
> > von Ticker Berkin 
> > Gesendet: Mittwoch, 15. April 2020 10:07
> > An: Development list for mkgmap
> > Betreff: Re: [mkgmap-dev] POI barrier/access restriction
> > 
> > Hi Gerd
> > 
> > I agree that OSM mappers don't always put the correct access rights
> > on
> > barriers, but often they do, and if wrong it can be corrected. I'm
> > not
> > sure what you mean by "hard to say what defaults should be used"?
> > 
> > I consider that this patch corrects flaws as I listed in the
> > interpreta
> > tion of OSM data relating to barriers and handles some more common
> > barrier types.
> > 
> > A couple of the fixes relate to transport modes I don't use
> > (goods/psv)
> > but the error and fix is textually obvious.
> > 
> > Others relate to combinations like [barrier=gate, vehicle=no],
> > because
> > vehicle is not expanded to bicycle, motorcar, etc.
> > 
> > A common problems I had was failure to route by car through a gate.
> > 
> > Another problem is [barrier={"bollard" etc}, access={anything but
> > "no"
> > or "private"], that would fail to impose a restriction on car, or,
> > indeed, any motor_vehicle
> > 
> > Ticker
> > 
> > On Tue, 2020-04-14 at 13:07 +, Gerd Petermann wrote:
> > > Hi Ticker,
> > > 
> > > it is difficult to find good rules for barriers Many people don't
> > > map
> > > the access rights and thus it is hard to say what defaults should
> > > be
> > > used.
> > > At least that was the case when I changed the rules in 2013 ;)
> > > 
> > > In what situations do you see improvements with your patch?
> > > 
> > > Gerd
> > > 
> > > 
> > > Von: mkgmap-dev  im
> > > Auftrag
> > > von Ticker Berkin 
> > > Gesendet: Montag, 13. April 2020 15:04
> > > An: Development list for mkgmap
> > > Betreff: Re: [mkgmap-dev] POI barrier/access restriction
> > > 
> > > Hi Gerd
> > > 
> > > The only common bit is filling in the mode hierarchy. It could be
> > > moved
> > > into an include and shared, but it is only 15 lines.
> > > 
> > > Ticker
> > > 
> > > On Mon, 2020-04-13 at 11:31 +, Gerd Petermann wrote:
> > > > Hi Ticker,
> > > > 
> > > > did not check the details yet but the patch seems to duplicate
> > > > a
> > > > lot
> > > > of stuff coded in inc/access. Is that needed?
> > > > 
> > > > Gerd
> > > > 
> > > > 
> > > > Von: mkgmap-dev  im
> > > > Auftrag
> > > > von Ticker Berkin 
> > > > Gesendet: Montag, 13. April 2020 13:21
> > > > An: mkgmap development
> > > > Betreff: [mkgmap-dev] POI barrier/access restriction
> > > > 
> > > > Hi Gerd and others interested in routing issues
> > > > 
> > > > default style "points" has code that, when option --link-pois
> > > > -to
> > > > -ways
> > > > is in effect, sets highway access and speed restrictions tha

Re: [mkgmap-dev] POI barrier/access restriction

[Ticker Berkin]

Hi Gerd

Yes, again mostly cattle grids in the UK, but sometimes these gates in
particular areas like the North Yorkshire moors.

Another common one is [barrier=lift-gate, access=customers] that
shouldn't prevent driving into a shop car-park.

Best wishes
Ticker

On Wed, 2020-04-15 at 09:15 +, Gerd Petermann wrote:
> Hi Ticker,
> 
> OK, thanks, committed with r4482. Seems the gate only exists to keep
> cattle inside an area? I think in Germany and Austria a cattle grid
> would be used.
> 
> Gerd
> 
> 
> Von: mkgmap-dev  im Auftrag
> von Ticker Berkin 
> Gesendet: Mittwoch, 15. April 2020 10:53
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] POI barrier/access restriction
> 
> Hi Gerd
> 
> For gate/lift_gate/swing_gate the new rules don't make any access
> assumptions, but any access/mode tags will be respected.
> 
> eg [barrier=gate, foot=yes, access=private] will set mkgmap:foot=yes
> and all the others to "no"
> 
> [barrier=swing_gate] would just imposes the speed penalty.
> 
> Ticker
> 
> On Wed, 2020-04-15 at 08:39 +, Gerd Petermann wrote:
> > Hi Ticker,
> > 
> > what are your assumptions reg. default access for a barrier=gate?
> > 
> > Gerd
> > 
> > 
> > Von: mkgmap-dev  im Auftrag
> > von Ticker Berkin 
> > Gesendet: Mittwoch, 15. April 2020 10:35
> > An: Development list for mkgmap
> > Betreff: Re: [mkgmap-dev] POI barrier/access restriction
> > 
> > Hi Gerd
> > 
> > Here is one, [barrier=gate] on [highway=unclassified]
> > 
> > https://www.openstreetmap.org/node/1394202186
> > 
> > Ticker
> > 
> > On Wed, 2020-04-15 at 08:13 +, Gerd Petermann wrote:
> > > Hi Ticker,
> > > 
> > > I think the patch looks good, I hoped for some samples where a
> > > correctly mapped barrier on a correctly mapped way shows problems
> > > with the existing rules ,e.g. "failure to route by car through a
> > > gate".
> > > 
> > > Gerd
> > > 
> > > 
> > > Von: mkgmap-dev  im
> > > Auftrag
> > > von Ticker Berkin 
> > > Gesendet: Mittwoch, 15. April 2020 10:07
> > > An: Development list for mkgmap
> > > Betreff: Re: [mkgmap-dev] POI barrier/access restriction
> > > 
> > > Hi Gerd
> > > 
> > > I agree that OSM mappers don't always put the correct access
> > > rights
> > > on
> > > barriers, but often they do, and if wrong it can be corrected.
> > > I'm
> > > not
> > > sure what you mean by "hard to say what defaults should be used"?
> > > 
> > > I consider that this patch corrects flaws as I listed in the
> > > interpreta
> > > tion of OSM data relating to barriers and handles some more
> > > common
> > > barrier types.
> > > 
> > > A couple of the fixes relate to transport modes I don't use
> > > (goods/psv)
> > > but the error and fix is textually obvious.
> > > 
> > > Others relate to combinations like [barrier=gate, vehicle=no],
> > > because
> > > vehicle is not expanded to bicycle, motorcar, etc.
> > > 
> > > A common problems I had was failure to route by car through a
> > > gate.
> > > 
> > > Another problem is [barrier={"bollard" etc}, access={anything but
> > > "no"
> > > or "private"], that would fail to impose a restriction on car,
> > > or,
> > > indeed, any motor_vehicle
> > > 
> > > Ticker
> > > 
> > > On Tue, 2020-04-14 at 13:07 +, Gerd Petermann wrote:
> > > > Hi Ticker,
> > > > 
> > > > it is difficult to find good rules for barriers Many people
> > > > don't
> > > > map
> > > > the access rights and thus it is hard to say what defaults
> > > > should
> > > > be
> > > > used.
> > > > At least that was the case when I changed the rules in 2013 ;)
> > > > 
> > > > In what situations do you see improvements with your patch?
> > > > 
> > > > Gerd
> > > > 
> > > > 
> > > > Von: mkgmap-dev  im
> > > > Auftrag
> > > > von Ticker Berkin 
> > > > Gesendet: Montag, 13. April 2020 15:04
> > > > An: Devel

[mkgmap-dev] [Fwd: Re: Suggestions for roadNameConfig.txt]

[Ticker Berkin]

Hi Gerd

Could you consider this change to roadNameConfig.txt for GBR

I've attached an updated version based current trunk.o1

Thank you
Ticker

 Forwarded Message 
From: Ticker Berkin 
Reply-to: Development list for mkgmap 
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] Suggestions for roadNameConfig.txt
Date: Thu, 23 Jan 2020 16:56:17 +

Hi Gerd

I've just been going through some old mails/patches.

I think the updated contents of roadNameConfig.txt is correct and
better than the previous version.

The fact that it doesn't work consistently across devices and, on some,
is misleading shouldn't stop the file being available as an example in
the distribution.

The user has the choice about how to use it and it contains some
comments and a link relating to these problems.

I've attached an updated patch with UTF-8 encoding markers, a different
section for UK road names and improved some comments.

This file has always been read by mkgmap as UTF-8. The function of the
markers is to make editors aware of this; it contains characters
outside the 7-bit ascii range. 

Ticker

On Mon, 2019-12-16 at 11:30 +, Gerd Petermann wrote:
> Hi Ticker,
> 
> reg. search: You are probably right, address search works very
> different on the Garmin devices. On the Oregon, I have several
> dialogs, first to chose country, next to chose city or "all", next to
> type house number, last one asking for road name. In this dialog
> there is no autocompletion, I just have to type characters. Sometimes
> the device switches automatically to a result list while I am typing,
> sometimes it doesn't. When I press OK I get a list of matching roads.
> So, for the Oregon it works fine. Maybe it doesn't for those devices
> with auto-completion. Cannot test this right now. I tried it once
> with a Nüvi and it seemed to work well, but I don't own one.
> 
> Reg. combination of   --road-name-config and --split-name-index: Yes,
> this gives confusing results. Not sure if it worked better in the
> past.
> I tried with Essex extract:
> java -jar d:\mkgmap\dist\mkgmap.jar --bounds=f:\osm\bounds.zip -
> -gmapi --net --index  --road-name
> -config=d:\mkgmap\resources\roadNameConfig.txt --gmapsupp --split
> -name-index f:\dwnload\temp\essex-latest.osm.pbf
> 
> 
> According to Mapsource a search for "Mace" without giving a city name
> should list "John Mace Road", "Mace Avenue", "Mace Court", and "Mace
> Walk", maybe in a different order.
> Without your patch I  get a list showing "Mace Road", "Mace Avenue",
> and "Mace Walk", so "Mace Court" is missing and when I select "Mace
> Road" the device shows the "John Mace Road".
> With your patch this gets worse: The list shows only "Mace Road",
> when I select that entry I get a new list containing
> ",Thurrock","Braintree,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 to do more tests, I think it worked better in the past. Maybe
> sorting is broken.
> 
> Gerd

Index: resources/roadNameConfig.txt
===
--- resources/roadNameConfig.txt	(revision 4482)
+++ resources/roadNameConfig.txt	(working copy)
@@ -1,16 +1,21 @@
-# Sample configuration file for road name prefixes and suffixes for use 
-# with the --road-name-config option.
+# Sample configuration file for use with the --road-name-config option.
+# -*- coding: UTF-8 -*-
+
+# This gives road name prefixes and suffixes in various languages.
 # A road name like West Main Street is separated into a prefix 'West',
-# the important part 'Main', and the suffix 'Street'.  
+# the important part 'Main', and the suffix 'Street'.
 
 # The first section lists often used prefixes and suffixes for a language.
 # The next section is used to configure which languages are used for road names
-# in each country.  
+# in each country.
 
-# Note that the order of the options doesn't matter, as well as the position 
+# Note that the order of the options doesn't matter, as well as the position
 # in the comma separated lists. Very important is the proper usage of blanks
 # within the quotation marks as well as the spelling.
 
+# Having suffixes makes Find>Address less easy to use on some GPS devices! See posting 21-Feb-2019:
+#  http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2019q1/029506.html
+
 ##
 # Section 1
 # prefix1: lis

Re: [mkgmap-dev] [Fwd: Re: Suggestions for roadNameConfig.txt]

[Ticker Berkin]

Hi Gerd

I did think about this, but --road-names-config is optional and behaves
as the documentation suggests and this patch includes a reasonably
complete list of suffixes for the UK and useful comments.

I tried it on my device and didn't like the effect and so don't use it,
Others might like it.

I've fixed Boulevard.

Ticker

On Thu, 2020-04-16 at 09:04 +, Gerd Petermann wrote:
> Hi Ticker,
> 
> did you consider disabling this feature for the UK? It looks wrong to
> me to have such a long list of rather meaningful names.
> 
> BTW: Boulivard is probably a typo?
> 
> Gerd
> 
> ____
> Von: mkgmap-dev  im Auftrag
> von Ticker Berkin 
> Gesendet: Donnerstag, 16. April 2020 10:35
> An: mkgmap development
> Betreff: [mkgmap-dev] [Fwd: Re:  Suggestions for roadNameConfig.txt]
> 
> Hi Gerd
> 
> Could you consider this change to roadNameConfig.txt for GBR
> 
> I've attached an updated version based current trunk.o1
> 
> Thank you
> Ticker
> 
>  Forwarded Message 
> From: Ticker Berkin 
> Reply-to: Development list for mkgmap  >
> To: Development list for mkgmap 
> Subject: Re: [mkgmap-dev] Suggestions for roadNameConfig.txt
> Date: Thu, 23 Jan 2020 16:56:17 +
> 
> Hi Gerd
> 
> I've just been going through some old mails/patches.
> 
> I think the updated contents of roadNameConfig.txt is correct and
> better than the previous version.
> 
> The fact that it doesn't work consistently across devices and, on
> some,
> is misleading shouldn't stop the file being available as an example
> in
> the distribution.
> 
> The user has the choice about how to use it and it contains some
> comments and a link relating to these problems.
> 
> I've attached an updated patch with UTF-8 encoding markers, a
> different
> section for UK road names and improved some comments.
> 
> This file has always been read by mkgmap as UTF-8. The function of
> the
> markers is to make editors aware of this; it contains characters
> outside the 7-bit ascii range.
> 
> Ticker
> 
> On Mon, 2019-12-16 at 11:30 +, Gerd Petermann wrote:
> > Hi Ticker,
> > 
> > reg. search: You are probably right, address search works very
> > different on the Garmin devices. On the Oregon, I have several
> > dialogs, first to chose country, next to chose city or "all", next
> > to
> > type house number, last one asking for road name. In this dialog
> > there is no autocompletion, I just have to type characters.
> > Sometimes
> > the device switches automatically to a result list while I am
> > typing,
> > sometimes it doesn't. When I press OK I get a list of matching
> > roads.
> > So, for the Oregon it works fine. Maybe it doesn't for those
> > devices
> > with auto-completion. Cannot test this right now. I tried it once
> > with a Nüvi and it seemed to work well, but I don't own one.
> > 
> > Reg. combination of   --road-name-config and --split-name-index:
> > Yes,
> > this gives confusing results. Not sure if it worked better in the
> > past.
> > I tried with Essex extract:
> > java -jar d:\mkgmap\dist\mkgmap.jar --bounds=f:\osm\bounds.zip -
> > -gmapi --net --index  --road-name
> > -config=d:\mkgmap\resources\roadNameConfig.txt --gmapsupp --split
> > -name-index f:\dwnload\temp\essex-latest.osm.pbf
> > 
> > 
> > According to Mapsource a search for "Mace" without giving a city
> > name
> > should list "John Mace Road", "Mace Avenue", "Mace Court", and
> > "Mace
> > Walk", maybe in a different order.
> > Without your patch I  get a list showing "Mace Road", "Mace
> > Avenue",
> > and "Mace Walk", so "Mace Court" is missing and when I select "Mace
> > Road" the device shows the "John Mace Road".
> > With your patch this gets worse: The list shows only "Mace Road",
> > when I select that entry I get a new list containing
> > ",Thurrock","Braintree,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 to do more tests, I think it worked better in the past.
> > Maybe
> > sorting is broken.
> > 
> > Gerd
> 
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists

Re: [mkgmap-dev] [Fwd: Re: Suggestions for roadNameConfig.txt]

[Ticker Berkin]

Hi Gerd

To be used for GBR, the prefix list need to different (actually empty),
compared with some other English speaking countries and my patch
includes this change and comments on the reason for it.

Then, in GBR, there are many suffixes, and again, I've generated and
included a comprehensive list.

Finally, actually using this on my 2 different eTrex devices, the
effects made address searching less obvious, in different ways, on the
2 devices. I put a reference to a post about this in the file.

Other devices might behave in what I would consider a better way, or
other people might consider the behaviour I see as perfectly
acceptable. 

I could comment out the suffix list for GBR, leaving both lists empty,
but it is easier not to use --road-name-config.

I don't understand your reluctance to accept these changes.

Ticker

On Thu, 2020-04-16 at 11:28 +, Gerd Petermann wrote:
> Hi Ticker,
> 
> You say you don't like the result.
> Does that mean you like it more with your long list of suffixes than
> with the short one?
> I worry about road names like "The Parade". I didn't try it again but
> I think the suffixes are assumed to have no meaning without other
> words . In Germany, you rarely find a road with the suffix "Straße"
> that has a name like "Die Straße".
> 
> I think it would be better to remove the defaults for GBR and wait
> until someone says that they are missing it.
> 
> Gerd
> 
> 
> Von: mkgmap-dev  im Auftrag
> von Ticker Berkin 
> Gesendet: Donnerstag, 16. April 2020 13:09
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] [Fwd: Re:  Suggestions for
> roadNameConfig.txt]
> 
> Hi Gerd
> 
> I did think about this, but --road-names-config is optional and
> behaves
> as the documentation suggests and this patch includes a reasonably
> complete list of suffixes for the UK and useful comments.
> 
> I tried it on my device and didn't like the effect and so don't use
> it,
> Others might like it.
> 
> I've fixed Boulevard.
> 
> Ticker
> 
> On Thu, 2020-04-16 at 09:04 +, Gerd Petermann wrote:
> > Hi Ticker,
> > 
> > did you consider disabling this feature for the UK? It looks wrong
> > to
> > me to have such a long list of rather meaningful names.
> > 
> > BTW: Boulivard is probably a typo?
> > 
> > Gerd
> > 
> > 
> > Von: mkgmap-dev  im Auftrag
> > von Ticker Berkin 
> > Gesendet: Donnerstag, 16. April 2020 10:35
> > An: mkgmap development
> > Betreff: [mkgmap-dev] [Fwd: Re:  Suggestions for
> > roadNameConfig.txt]
> > 
> > Hi Gerd
> > 
> > Could you consider this change to roadNameConfig.txt for GBR
> > 
> > I've attached an updated version based current trunk.o1
> > 
> > Thank you
> > Ticker
> > 
> >  Forwarded Message 
> > From: Ticker Berkin 
> > Reply-to: Development list for mkgmap <
> > mkgmap-dev@lists.mkgmap.org.uk
> > > 
> > To: Development list for mkgmap 
> > Subject: Re: [mkgmap-dev] Suggestions for roadNameConfig.txt
> > Date: Thu, 23 Jan 2020 16:56:17 +
> > 
> > Hi Gerd
> > 
> > I've just been going through some old mails/patches.
> > 
> > I think the updated contents of roadNameConfig.txt is correct and
> > better than the previous version.
> > 
> > The fact that it doesn't work consistently across devices and, on
> > some,
> > is misleading shouldn't stop the file being available as an example
> > in
> > the distribution.
> > 
> > The user has the choice about how to use it and it contains some
> > comments and a link relating to these problems.
> > 
> > I've attached an updated patch with UTF-8 encoding markers, a
> > different
> > section for UK road names and improved some comments.
> > 
> > This file has always been read by mkgmap as UTF-8. The function of
> > the
> > markers is to make editors aware of this; it contains characters
> > outside the 7-bit ascii range.
> > 
> > Ticker
> > 
> > On Mon, 2019-12-16 at 11:30 +, Gerd Petermann wrote:
> > > Hi Ticker,
> > > 
> > > reg. search: You are probably right, address search works very
> > > different on the Garmin devices. On the Oregon, I have several
> > > dialogs, first to chose country, next to chose city or "all",
> > > next
> > > to
> > > type house number, last one asking for road name. In this dialog
> > > there is 

Re: [mkgmap-dev] [Fwd: Re: Suggestions for roadNameConfig.txt]

[Ticker Berkin]

Hi Gerd

Here is a patch with the GBR suffixes commented out.

Ticker


On Fri, 2020-04-17 at 08:39 +, Gerd Petermann wrote:
> > I don't understand your reluctance to accept these changes.
> When I added the code for option --road-name-config I was already
> unsure if this feature makes sense in countries with English or
> German road names
> or more generally speaking if it makes sense with suffixes.
> I think it can help for latin based languages like Frensh, Italian,
> Portugese, Spanish, and alike, but also only without --split-name
> -index.
> 
> Your long list somehow implies that the feature works well when you
> add lots of possible suffixes, I think it only works well the list is
> short.
> Since we both don't like the results of the function I'd prefer to
> comment the lists.
> 
> Would be good to know if those how contributed to it (Alexandre Folle
> de Menezes and Carlos Davida) use it with Maps for the UK.
> 
> Gerd
> 
> ________
> Von: mkgmap-dev  im Auftrag
> von Ticker Berkin 
> Gesendet: Freitag, 17. April 2020 10:13
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] [Fwd: Re:  Suggestions for
> roadNameConfig.txt]
> 
> Hi Gerd
> 
> To be used for GBR, the prefix list need to different (actually
> empty),
> compared with some other English speaking countries and my patch
> includes this change and comments on the reason for it.
> 
> Then, in GBR, there are many suffixes, and again, I've generated and
> included a comprehensive list.
> 
> Finally, actually using this on my 2 different eTrex devices, the
> effects made address searching less obvious, in different ways, on
> the
> 2 devices. I put a reference to a post about this in the file.
> 
> Other devices might behave in what I would consider a better way, or
> other people might consider the behaviour I see as perfectly
> acceptable.
> 
> I could comment out the suffix list for GBR, leaving both lists
> empty,
> but it is easier not to use --road-name-config.
> 
> I don't understand your reluctance to accept these changes.
> 
> Ticker
> 
> On Thu, 2020-04-16 at 11:28 +, Gerd Petermann wrote:
> > Hi Ticker,
> > 
> > You say you don't like the result.
> > Does that mean you like it more with your long list of suffixes
> > than
> > with the short one?
> > I worry about road names like "The Parade". I didn't try it again
> > but
> > I think the suffixes are assumed to have no meaning without other
> > words . In Germany, you rarely find a road with the suffix "Straße"
> > that has a name like "Die Straße".
> > 
> > I think it would be better to remove the defaults for GBR and wait
> > until someone says that they are missing it.
> > 
> > Gerd
> > 
> > 
> > Von: mkgmap-dev  im Auftrag
> > von Ticker Berkin 
> > Gesendet: Donnerstag, 16. April 2020 13:09
> > An: Development list for mkgmap
> > Betreff: Re: [mkgmap-dev] [Fwd: Re:  Suggestions for
> > roadNameConfig.txt]
> > 
> > Hi Gerd
> > 
> > I did think about this, but --road-names-config is optional and
> > behaves
> > as the documentation suggests and this patch includes a reasonably
> > complete list of suffixes for the UK and useful comments.
> > 
> > I tried it on my device and didn't like the effect and so don't use
> > it,
> > Others might like it.
> > 
> > I've fixed Boulevard.
> > 
> > Ticker
> > 
> > On Thu, 2020-04-16 at 09:04 +, Gerd Petermann wrote:
> > > Hi Ticker,
> > > 
> > > did you consider disabling this feature for the UK? It looks
> > > wrong
> > > to
> > > me to have such a long list of rather meaningful names.
> > > 
> > > BTW: Boulivard is probably a typo?
> > > 
> > > Gerd
> > > 
> > > 
> > > Von: mkgmap-dev  im
> > > Auftrag
> > > von Ticker Berkin 
> > > Gesendet: Donnerstag, 16. April 2020 10:35
> > > An: mkgmap development
> > > Betreff: [mkgmap-dev] [Fwd: Re:  Suggestions for
> > > roadNameConfig.txt]
> > > 
> > > Hi Gerd
> > > 
> > > Could you consider this change to roadNameConfig.txt for GBR
> > > 
> > > I've attached an updated version based current trunk.o1
> > > 
> > > Thank you
> > > Ticker
> > > 
> > >  Forwarded Message 
> > > From: T

Re: [mkgmap-dev] nearby POIs

[Ticker Berkin]

Hi Eric

I disagree that coincident POI are useless, eg if
  [tourism=hotel, amenity=restaurant] were to generate:
  POI 0x2b01 (Lodgings>Hotel/Motel) and 
  POI 0x2a00 (Food&Drink>All)
then searching for either gives the correct answer - just what I would
want. I implement this in my style.

Concerning your other examples; something similar could be done for
Cafe/Bakery as this is quite common and useful, but I found there were
far to many minor amenity= to bother with, so ignoring all but the
major ones, you just get the POI for viewpoint

Ticker


On Wed, 2020-04-22 at 01:04 -0700, AnkEric wrote:
> Mike:/ "handling the *removal* of *duplicate *POIs that are *near* to
> each
> other but *not coincident*."/
> 
> Very useful! 
> In the Netherlands I was involved in a discussion:
> Set [man_made=windmill] on POI-address-node (is rendered by JOSM and
> links
> address to POI) or Set on building (a windmill is not a node, but a
> building, but building tag is not rendered by JOSM)?
> 
> Now solution has become "simple": set [man_made=windmill] on both
> "POI-address-node" and on building. Win-win situation thanks to Mike.
> 
> But... also...
> 
> http://gis.19327.n8.nabble.com/One-object-has-more-than-one-POI-tag-H
> otel-Cafe-Restaurant-td5960958.html
> 
> One object has (or should have) more than one POI-tags. Examples:
> - tourism=hotel; amenity=restaurant
> - historic=building; man_made=windmill
> - shop=bakery; amenity=café ("konditorei")
> - amenity=bench; tourism=viewpoint
> - amenity=bench; tourism= artwork
> 
> Gerd: /"2) You can create *multiple *POI using the *continue
> *statement."/
> 
> Yes, I can but now different POI's are on same location, which makes
> both
> POI's useless (mixed together).
> 
> Mike:/ "<...> but the location of the *existing* point is *"MOVED"*
> to a
> point midway between the two points"./
> 
> Question: Is "moving" a "different POI" on the "same object" an
> *extra
> option* to resolve "mixed together" POI's?
> 
> I know: not using "continue" will resolve (Renderer should decide
> what's
> more important: hotel *or* restaurant), but also implies a loss of
> information.
> 
> 
> 
> --
> Sent from: 
> http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] default style points enhancements

[Ticker Berkin]

Hi Gerd and followers of the default style

Here are some enhancements to default style "points" - patch attached.

I've been building up a list of changes to the default style for a
while, and, with the current discussion about multiple POI for a single
OSM object and the benefit of benches (I've just added this), it seemed
like a good time to put forward these changes. 

Some of these derive from:
http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2019q4/030097.html

Some from other comments in this forum and the rest are from when I've
noticed something wrong or that could be improved.

Summary of changes:
- for amenity={atm/bar/cafe} allow additional POI from other tags,
  eg shop=bakery or any others: leisure/tourism/sport/...=...
- create POI 0x6605 for bench (Geographic>Land>Bench)
- don't create POI for private parking
- create parking POI for parking_entrance
- if parking unnamed, use access tag if exists, giving names like
  "Customer parking", "Permissive parking"...
- explicit shelter_type=basic_hut rather that trying to exclude
  bus shelters etc for Find>Lodgings
- marina code from 0x4300 to 0x2f09; searchable as "Others"
- POI for nature_reserve, even if not named
- don't create POI for pitch if no name or sport
- don't create POI for private swimming pools
- don't create POI for unnamed cliff
- add POI 0x6503 for named bay (Geographic>Water>Bay)
- for platforms, just 1 POI when --add-pois-to-lines
- name unnamed shops as category, regardless of category being matched
- add, commented out, extra shop categories supported by some devices
- add POI for shop=outdoor
- for {camp/caravan}_site have BOTH 0x2b03 AND 0x2b05;
  03 not shown on modern devices, 05 not shown on old devices
- have both Food & Lodging POI for same point if appropriate
- landuse=basin code from 0x650f (Geographic>Water>Reservoir)
   to 0x6603 (Geographic>Land>Basin)
- water=reservoir as well as landuse=reservoir
- add POI 0x650d for named water=lake/pond (Geograhic>Water>Lake)

I'm happy to explain any of these change in more detail and, if anyone
considers a particular change incorrect, provide a revised patch.

Ticker
Index: resources/styles/default/points
===
--- resources/styles/default/points	(revision 4483)
+++ resources/styles/default/points	(working copy)
@@ -119,14 +119,15 @@
 aeroway=helipad [0x5904 resolution 23]
 aeroway=terminal [0x2f04 resolution 24]
 
-amenity=atm [0x2f06 resolution 24]
+amenity=atm [0x2f06 resolution 24 continue]
 amenity=arts_centre [0x2c04 resolution 24]
 amenity=bank [0x2f06 resolution 24]
-amenity=bar [0x2d02 resolution 24]
+amenity=bar [0x2d02 resolution 24 continue]
+amenity=bench [0x6605 resolution 24 continue]
 amenity=biergarten [0x2d02 resolution 24]
 amenity=border_control | barrier=border_control [0x3006 resolution 20]
 amenity=bus_station [0x2f08 resolution 23]
-amenity=cafe [0x2a0e resolution 24]
+amenity=cafe {delete cuisine} [0x2a0e resolution 24 continue with_actions]
 amenity=car_club [0x2f0d resolution 24]
 amenity=car_rental [0x2f02 resolution 24]
 amenity=car_sharing [0x2f02 resolution 24]
@@ -157,7 +158,7 @@
 amenity=library [0x2c03 resolution 24]
 amenity=nightclub [0x2d02 resolution 24]
 amenity=nursing_home [0x2f14 resolution 24]
-amenity=parking [0x2f0b resolution 24 default_name 'Parking']
+(amenity=parking | amenity=parking_entrance) & access!=private & access!=no {add name='${access} parking'| 'Parking'} [0x2f0b resolution 24]
 amenity=pharmacy [0x2e05 resolution 24]
 amenity=place_of_worship [0x2c0b resolution 24]
 amenity=police [0x3001 resolution 24]
@@ -172,7 +173,7 @@
 # amenity=shelter is ambiguous; when possible, consider using other tags:
 #  tourism=lean_to or tourism=picnic_site
 #  shelter=yes on highway=bus_stop or highway=tram_stop or railway=halt
-amenity=shelter & shelter_type!=public_transport [0x2b06 resolution 24 default_name 'Shelter']
+amenity=shelter & shelter_type=basic_hut [0x2b06 resolution 24 default_name 'Shelter']
 # amenity=supermarket is superceded by shop=supermarket
 amenity=supermarket [0x2e02 resolution 24]
 amenity=taxi [0x2f17 resolution 24]
@@ -202,15 +203,15 @@
 leisure=garden & name=* [0x2c06 resolution 24]
 leisure=golf_course [0x2d05 resolution 24]
 leisure=ice_rink [0x2d08 resolution 24]
-leisure=marina [0x4300 resolution 24]
-leisure=nature_reserve & name=* [0x6612 resolution 24]
+leisure=marina [0x2f09 resolution 24]
+leisure=nature_reserve [0x6612 resolution 24]
 leisure=park [0x2c06 resolution 24]
-leisure=pitch {name '${name} (${sport})' | '${sport}'} [0x2c08 resolution 24]
+leisure=pitch & (name=* | sport=*) {name '${name} (${sport})' | '${sport}'} [0x2c08 resolution 24]
 leisure=playground [0x2c06 resolution 24 default_name 'Playground']
 leisure=recreation_ground [0x2c08 resolution 24 default_name 'Rec.']
 leisure=sports_center | leisure=sports_centre {name '${name} (${sport})' | '${sport}'} [0x2d0a resolution 24]
 leisure=stadium {name

Re: [mkgmap-dev] default style points enhancements

[Ticker Berkin]

Hi Eric

Happy to add:
 leisure=picnic_table
to my proposed change list, using the same code as picnic_site (0x4a00,
"Picnic Area", not searchable)

I don't want to look through spreadsheets; if there are comments
relevant to default style "points", please just post them as text.

Also, all the codes in "points" render nicely on old devices without
any TYP file, and are chosen to match, if as far as possible, the
device FIND> functionality. mapnik.txt is not a consideration.

Ticker

On Wed, 2020-04-22 at 08:07 -0700, AnkEric wrote:
> Nice!
> 
> I have reviewed mapnik.txt in relation to default style.
> Now I'm capable of generating (in automation) an Excel showing all
> tags,
> values and usage.
> Also for my own style. 
> 
> TYPFILE_mapnik_2020-04-22.xlsx
>  2.xlsx>  ;
> 
> In this Excel I have made some remarks or suggestions (in red).
> Of course this was a manual action.
> 
> TYPFILE_Mapnik_Reviewed.xlsx
>  xlsx>  ;
> 
> In your list of POI's I miss:
> 
> - leisure=picnic_table
> 
> picnic_site most often has also a picnic_table, but not always.
> picnic_site might have more objects (hut, shelter, benches, drinking
> water,
> barbecue, fireplace).
> Or picnic_site is just a nice view only, no amenity.
> In wet circumstances we are only interested in picnic_table, not in
> picnic_site.
> leisure=picnic_table is a de facto tag since 2014. Rendered by JOSM
> since
> 2014.
> 
> 
> 
> 
> 
> 
> 
> --
> Sent from: 
> http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] [Fwd: Re: Suggestions for roadNameConfig.txt]

[Ticker Berkin]

Hi Gerd

Could you apply this patch

Thanks
Ticker

On Fri, 2020-04-17 at 10:18 +0100, Ticker Berkin wrote:
> Hi Gerd
> 
> Here is a patch with the GBR suffixes commented out.
> 
> Ticker
Index: resources/roadNameConfig.txt
===
--- resources/roadNameConfig.txt	(revision 4482)
+++ resources/roadNameConfig.txt	(working copy)
@@ -1,16 +1,21 @@
-# Sample configuration file for road name prefixes and suffixes for use 
-# with the --road-name-config option.
+# Sample configuration file for use with the --road-name-config option.
+# -*- coding: UTF-8 -*-
+
+# This gives road name prefixes and suffixes in various languages.
 # A road name like West Main Street is separated into a prefix 'West',
-# the important part 'Main', and the suffix 'Street'.  
+# the important part 'Main', and the suffix 'Street'.
 
 # The first section lists often used prefixes and suffixes for a language.
 # The next section is used to configure which languages are used for road names
-# in each country.  
+# in each country.
 
-# Note that the order of the options doesn't matter, as well as the position 
+# Note that the order of the options doesn't matter, as well as the position
 # in the comma separated lists. Very important is the proper usage of blanks
 # within the quotation marks as well as the spelling.
 
+# Having suffixes makes Find>Address less easy to use on some GPS devices! See posting 21-Feb-2019:
+#  http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2019q1/029506.html
+
 ##
 # Section 1
 # prefix1: list of 1st words
@@ -25,8 +30,14 @@
 prefix2:ca = "de las ", "de los ", "de la ", "del ", "de ", "d'"
 
 # english
-prefix1:en = "East ", "North ", "South ", "West " 
+prefix1:en = "East ", "North ", "South ", "West "
 suffix:en = " Road", " Street"
+#
+# UK road names don't have prefixes, eg "North View" and "South View" are unlikely to be connected.
+# So, via Section 2 (country to language mapping), have different prefix/suffix for the UK:
+#prefix1:en_gb = empty
+# Also some devices make address searching counter-intuitive when there are suffix, so don't have these either
+#suffix:en_gb = " Arcade", " Avenue", " Boulevard", " Circus", " Close", " Court", " Crescent", " Croft", " Drive", " Field", " Fields", " Gardens", " Gate", " Grove", " Hill", " Lane", " Mews", " Parade", " Park", " Passage", " Place", " Rise", " Road", " Square", " Street", " Terrace", " View", " Villas", " Walk", " Way", " Wood", " Yard"
 
 # french
 prefix1:fr = "Allée", "Avenue", "Boulevard", "Chemin", "Place", "Rue", "Route"
@@ -54,7 +65,7 @@
 ##
 # Section 2
 # Map three letter ISO country codes to list of used languages for road names.
-# It is assumed that the style sets mkgmap:country to one of these ISO codes.
+# It is assumed that the style sets mkgmap:country to one of these ISO codes.
 
 lang:AGO = pt
 lang:AND = es, ca
@@ -73,7 +84,7 @@
 lang:ESH = es
 lang:ESP = es, gl, eu, ca
 lang:FRA = fr
-lang:GBR = en
+lang:GBR = en_gb
 lang:GNB = pt
 lang:GTM = es
 lang:GUY = en
@@ -90,3 +101,5 @@
 lang:URI = es
 lang:USA = en
 lang:VEN = es
+
+# End Section 2
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] [Fwd: Re: Suggestions for roadNameConfig.txt]

[Ticker Berkin]

Hi Gerd

Yes, I'd be happy to accept this.

The problem with having suffixes wasn't that "the user must know them
when searching for roads". It was that, at least for my eTrex, there is
just a single entry in the STREET part of the search for all suffix
variants, and then, after selecting that, all address in all variants
are given in the result list.

I've included Dave's additions for mapping some Africa countries to
en_gb in an updated patch.

Ticker


On Mon, 2020-04-27 at 13:54 +, Gerd Petermann wrote:
> Hi Ticker,
> 
> I've attached a slightly modified version which I would accept.
> My understanding is that the user must know the common suffixes
> configured in the list when searching for roads. The long list is
> much too long to remember.
> So, I'd prefer to omit the list and just explain that the use of -
> -road-name-config makes no sense in the UK.
> 
> Gerd
> 
> 
> ____
> Von: mkgmap-dev  im Auftrag
> von Ticker Berkin 
> Gesendet: Montag, 27. April 2020 15:20
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] [Fwd: Re:  Suggestions for
> roadNameConfig.txt]
> 
> Hi Gerd
> 
> Could you apply this patch
> 
> Thanks
> Ticker
> 
> On Fri, 2020-04-17 at 10:18 +0100, Ticker Berkin wrote:
> > Hi Gerd
> > 
> > Here is a patch with the GBR suffixes commented out.
> > 
> > Ticker
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-devIndex: resources/roadNameConfig.txt
===
--- resources/roadNameConfig.txt	(revision 4483)
+++ resources/roadNameConfig.txt	(working copy)
@@ -1,16 +1,21 @@
-# Sample configuration file for road name prefixes and suffixes for use 
-# with the --road-name-config option.
+# Sample configuration file for use with the --road-name-config option.
+# -*- coding: UTF-8 -*-
+
+# This gives road name prefixes and suffixes in various languages.
 # A road name like West Main Street is separated into a prefix 'West',
-# the important part 'Main', and the suffix 'Street'.  
+# the important part 'Main', and the suffix 'Street'.
 
 # The first section lists often used prefixes and suffixes for a language.
 # The next section is used to configure which languages are used for road names
-# in each country.  
+# in each country.
 
-# Note that the order of the options doesn't matter, as well as the position 
+# Note that the order of the options doesn't matter, as well as the position
 # in the comma separated lists. Very important is the proper usage of blanks
 # within the quotation marks as well as the spelling.
 
+# Having suffixes makes Find>Address less easy to use on some GPS devices! See posting 21-Feb-2019:
+#  http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2019q1/029506.html
+
 ##
 # Section 1
 # prefix1: list of 1st words
@@ -25,8 +30,14 @@
 prefix2:ca = "de las ", "de los ", "de la ", "del ", "de ", "d'"
 
 # english
-prefix1:en = "East ", "North ", "South ", "West " 
+prefix1:en = "East ", "North ", "South ", "West "
 suffix:en = " Road", " Street"
+#
+# UK road names don't have prefixes, eg "North View" and "South View" are unlikely to be connected.
+# So, via Section 2 (country to language mapping), have different prefix/suffix for the UK:
+#prefix1:en_gb = empty
+# UK road names have many different suffixes and should not be used as they make address searching counter-intuitive
+#suffix:en_gb = " Arcade", " Avenue", " Boulevard", " Circus", " Close", " Court", " Crescent", " Croft", " Drive", " Field", " Fields", " Gardens", " Gate", " Grove", " Hill", " Lane", " Mews", " Parade", " Park", " Passage", " Place", " Rise", " Road", " Square", " Street", " Terrace", " View", " Villas", " Walk", " Way", " Wood", " Yard"
 
 # french
 prefix1:fr = "Allée", "Avenue", "Boulevard", "Chemin", "Place", "Rue", "Route"
@@ -54,13 +65,17 @@
 ##
 # Section 2
 # Map three letter ISO country codes to list of used languages for road names.

[mkgmap-dev] nearby POIs

[Ticker Berkin]

Hi Mike & Gerd

I'm trying --nearby-poi-rules=0x6605:30:merge-at-mid-point

with, in points:

amenity=bench [0x6605 resolution 24 continue]

and the resultant map is showing benches close to each other (< 10 m)

and, in the log file I'm getting messages like:

INFO: uk.me.parabola.mkgmap.osmstyle.NearbyPoiHandler 
 ../mapHants/74210001.osm.pbf: Removed duplicate POI with type 0x2d02
The Dungeon for element generated from 159255400
INFO: uk.me.parabola.mkgmap.osmstyle.NearbyPoiHandler 
 ../mapHants/74210001.osm.pbf: Removed duplicate POI with type 0x2a07
Wah Ying for element generated from 468906008

The "generated from" number doesn't seem to correspond to a relevant
OSM node and the message doesn't have the trailing "and moved..." that
I would have expected.

Ticker
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] nearby POIs

[Ticker Berkin]

OK, looking up the # as a way instead gives a polygon that matches the
description and would generate a typ code as per the message

I was more worried about it logging messages about POI with typ codes
that I hadn't mentioned in rules and not saying anything about the one
I had.

I get the same behaviour with just --nearby-poi-rules=0x6605:30
 
Ticker

On Mon, 2020-05-04 at 10:14 +, Gerd Petermann wrote:
> Hi Ticker,
> 
> the new option doesn't work well, Mike and I are working on it. See 
> http://gis.19327.n8.nabble.com/nearby-POIs-tp5962630p5964759.html
> The log messages are for POIs generated from areas, so the "generated
> from" ids are either ways or multipolygon relations.
> 
> Gerd
> 
> 
> ________
> Von: mkgmap-dev  im Auftrag
> von Ticker Berkin 
> Gesendet: Montag, 4. Mai 2020 12:04
> An: mkgmap development
> Betreff: [mkgmap-dev] nearby POIs
> 
> Hi Mike & Gerd
> 
> I'm trying --nearby-poi-rules=0x6605:30:merge-at-mid-point
> 
> with, in points:
> 
> amenity=bench [0x6605 resolution 24 continue]
> 
> and the resultant map is showing benches close to each other (< 10 m)
> 
> and, in the log file I'm getting messages like:
> 
> INFO: uk.me.parabola.mkgmap.osmstyle.NearbyPoiHandler
>  ../mapHants/74210001.osm.pbf: Removed duplicate POI with type 0x2d02
> The Dungeon for element generated from 159255400
> INFO: uk.me.parabola.mkgmap.osmstyle.NearbyPoiHandler
>  ../mapHants/74210001.osm.pbf: Removed duplicate POI with type 0x2a07
> Wah Ying for element generated from 468906008
> 
> The "generated from" number doesn't seem to correspond to a relevant
> OSM node and the message doesn't have the trailing "and moved..."
> that
> I would have expected.
> 
> Ticker
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] nearby POIs

[Ticker Berkin]

Hi Mike

No, I just have --nearby-poi-rules=0x6605:30

Gerd has explained why I see a message from NearbyPoiHandler about a
POI for that wasn't 0x6605 - the logging of the removal of an exact
duplicate has moved from StyledConverter

Ticker

On Mon, 2020-05-04 at 14:35 +0100, Mike Baggaley wrote:
> Hi Ticker, have you got a --nearby-poi-rules-config option as well?
> 
> Cheers,
> Mike
> 
> -Original Message-
> From: Ticker Berkin [mailto:rwb-mkg...@jagit.co.uk] 
> Sent: 04 May 2020 11:33
> To: Development list for mkgmap 
> Subject: Re: [mkgmap-dev] nearby POIs
> 
> OK, looking up the # as a way instead gives a polygon that matches
> the
> description and would generate a typ code as per the message
> 
> I was more worried about it logging messages about POI with typ codes
> that I hadn't mentioned in rules and not saying anything about the
> one
> I had.
> 
> I get the same behaviour with just --nearby-poi-rules=0x6605:30
>  
> Ticker
> 
> On Mon, 2020-05-04 at 10:14 +, Gerd Petermann wrote:
> > Hi Ticker,
> > 
> > the new option doesn't work well, Mike and I are working on it. See
> > http://gis.19327.n8.nabble.com/nearby-POIs-tp5962630p5964759.html
> > The log messages are for POIs generated from areas, so the
> > "generated
> > from" ids are either ways or multipolygon relations.
> > 
> > Gerd
> > 
> > 
> > 
> > Von: mkgmap-dev  im Auftrag
> > von Ticker Berkin 
> > Gesendet: Montag, 4. Mai 2020 12:04
> > An: mkgmap development
> > Betreff: [mkgmap-dev] nearby POIs
> > 
> > Hi Mike & Gerd
> > 
> > I'm trying --nearby-poi-rules=0x6605:30:merge-at-mid-point
> > 
> > with, in points:
> > 
> > amenity=bench [0x6605 resolution 24 continue]
> > 
> > and the resultant map is showing benches close to each other (< 10
> > m)
> > 
> > and, in the log file I'm getting messages like:
> > 
> > INFO: uk.me.parabola.mkgmap.osmstyle.NearbyPoiHandler
> >  ../mapHants/74210001.osm.pbf: Removed duplicate POI with type
> > 0x2d02
> > The Dungeon for element generated from 159255400
> > INFO: uk.me.parabola.mkgmap.osmstyle.NearbyPoiHandler
> >  ../mapHants/74210001.osm.pbf: Removed duplicate POI with type
> > 0x2a07
> > Wah Ying for element generated from 468906008
> > 
> > The "generated from" number doesn't seem to correspond to a
> > relevant
> > OSM node and the message doesn't have the trailing "and moved..."
> > that
> > I would have expected.
> > 
> > Ticker
> > ___
> > mkgmap-dev mailing list
> > mkgmap-dev@lists.mkgmap.org.uk
> > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> > ___
> > mkgmap-dev mailing list
> > mkgmap-dev@lists.mkgmap.org.uk
> > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> 
> 
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] nearby POIs

[Ticker Berkin]

Hi Gerd

That got rid of my multiple benches.

Just looking at the log for the few other POI it also got rid of.

It would be useful for the log message to include the distance between
the POIs

Ticker

On Tue, 2020-05-05 at 09:19 +, Gerd Petermann wrote:
> Hi all,
> 
> attached is a patch that seems to work. I've kept the logging as
> memory is not such a big problem.
> I've not yet tested special cases like duplicated barrier nodes or a
> group of nodes where only some are within the tile boundary.
> 
> Please check if your problems are solved with this version, a binary
> is here:
> http://files.mkgmap.org.uk/download/469/mkgmap.jar
> 
> Gerd
> 
> 
> Von: mkgmap-dev  im Auftrag
> von Joris Bo 
> Gesendet: Dienstag, 5. Mai 2020 08:32
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] nearby POIs
> 
> Hi,
> 
> 
> 
> I have been testing the nearby poi rules as well with 4485
> 
> A while I struggled thinking misconfiguration because I see nothing
> happening but then after extending the ranges, an occasional poi
> disappears. (toilet 0x2a0d, busstop 0x2f17, custom lift-gate 0x6905)
> 
> 
> 
> On the cmd line
> 
> --nearby-poi-rules=*/unnamed:100:delete-poi,*/named:100:delete-poi
> 
> 
> 
> On my densed big city area (Antwerpen) In that case I expect maybe a
> couple of thousand benches, trees and bicycle parkings disappear
> which do not.
> 
> 
> 
> Can I help testing better by increasing some logging? How could I do
> that?
> 
> 
> 
> Kind regards, joris
> 
> 
> 
> Silo’s (0x2a19) don’t disappear / N51° 11.992' E4° 24.916'
> 
> An occasional lift gate (0x6905) does disappear
> 
> [cid:image001.jpg@01D622B7.BA7DE260]
> 
> 
> 
> Bicycle stands (0x2f18): don’t disappear
> 
> N51° 13.685' E4° 24.281'
> 
> [cid:image002.jpg@01D622B7.BA7DE260]
> 
> 
> 
> 
> 
> -Oorspronkelijk bericht-
> Van: mkgmap-dev  Namens
> Ticker Berkin
> Verzonden: maandag 4 mei 2020 16:13
> Aan: mkgmap development 
> Onderwerp: Re: [mkgmap-dev] nearby POIs
> 
> 
> 
> Hi Mike
> 
> 
> 
> No, I just have --nearby-poi-rules=0x6605:30
> 
> 
> 
> Gerd has explained why I see a message from NearbyPoiHandler about a
> POI for that wasn't 0x6605 - the logging of the removal of an exact
> duplicate has moved from StyledConverter
> 
> 
> 
> Ticker
> 
> 
> 
> On Mon, 2020-05-04 at 14:35 +0100, Mike Baggaley wrote:
> 
> > Hi Ticker, have you got a --nearby-poi-rules-config option as well?
> 
> > 
> 
> > Cheers,
> 
> > Mike
> 
> > 
> 
> > -Original Message-
> 
> > From: Ticker Berkin [mailto:rwb-mkg...@jagit.co.uk]
> 
> > Sent: 04 May 2020 11:33
> 
> > To: Development list for mkgmap  > lto:mkgmap-dev@lists.mkgmap.org.uk>>
> 
> > Subject: Re: [mkgmap-dev] nearby POIs
> 
> > 
> 
> > OK, looking up the # as a way instead gives a polygon that matches
> > the
> 
> > description and would generate a typ code as per the message
> 
> > 
> 
> > I was more worried about it logging messages about POI with typ
> > codes
> 
> > that I hadn't mentioned in rules and not saying anything about the
> > one
> 
> > I had.
> 
> > 
> 
> > I get the same behaviour with just --nearby-poi-rules=0x6605:30
> 
> > 
> 
> > Ticker
> 
> > 
> 
> > On Mon, 2020-05-04 at 10:14 +, Gerd Petermann wrote:
> 
> > > Hi Ticker,
> 
> > > 
> 
> > > the new option doesn't work well, Mike and I are working on it.
> > > See
> 
> > > http://gis.19327.n8.nabble.com/nearby-POIs-tp5962630p5964759.html
> 
> > > The log messages are for POIs generated from areas, so the
> 
> > > "generated from" ids are either ways or multipolygon relations.
> 
> > > 
> 
> > > Gerd
> 
> > > 
> 
> > > 
> 
> > > 
> 
> > > Von: mkgmap-dev  > > mkgmap-dev-boun...@lists.mkgmap.org.uk>> im Auftrag
> 
> > > von Ticker Berkin  > > rwb-mkg...@jagit.co.uk>>
> 
> > > Gesendet: Montag, 4. Mai 2020 12:04
> 
> > > An: mkgmap development
> 
> > > Betreff: [mkgmap-dev] nearby POIs
> 
> > > 
> 
> > > Hi Mike & Gerd
> 
> > > 
> 
> > > I'm trying --nearby-poi-rules=0x6605:30:merge-at-mid-point
> 
> > > 
> 
> > > with, in points:
> 
>

Re: [mkgmap-dev] nearby POIs

[Ticker Berkin]

Hi

In my sample I got 3 POIs removed with codes I didn't specify.
Two of these were duplicate areas in OSM and last was

INFO: uk.me.parabola.mkgmap.osmstyle.NearbyPoiHandler 
 ../mapHants/74210001.osm.pbf: Removed duplicate POI with type 0x3200
gate for element http://www.openstreetmap.org/node/2038594304 

which is a {barrier=gate,bicycle=yes,motor_vehicle=private} on a
footway. Maybe the footway is split at the gate to handle access and/or
mkgmap:road-speed and the POI gets duplicated.

Anyway, none of these indicate a problem.

Ticker

On Tue, 2020-05-05 at 11:03 +0100, Ticker Berkin wrote:
> Hi Gerd
> 
> That got rid of my multiple benches.
> 
> Just looking at the log for the few other POI it also got rid of.
> 
> It would be useful for the log message to include the distance
> between
> the POIs
> 
> Ticker
> 
> On Tue, 2020-05-05 at 09:19 +, Gerd Petermann wrote:
> > Hi all,
> > 
> > attached is a patch that seems to work. I've kept the logging as
> > memory is not such a big problem.
> > I've not yet tested special cases like duplicated barrier nodes or
> > a
> > group of nodes where only some are within the tile boundary.
> > 
> > Please check if your problems are solved with this version, a
> > binary
> > is here:
> > http://files.mkgmap.org.uk/download/469/mkgmap.jar
> > 
> > Gerd
> > 
> > 
> > Von: mkgmap-dev  im Auftrag
> > von Joris Bo 
> > Gesendet: Dienstag, 5. Mai 2020 08:32
> > An: Development list for mkgmap
> > Betreff: Re: [mkgmap-dev] nearby POIs
> > 
> > Hi,
> > 
> > 
> > 
> > I have been testing the nearby poi rules as well with 4485
> > 
> > A while I struggled thinking misconfiguration because I see nothing
> > happening but then after extending the ranges, an occasional poi
> > disappears. (toilet 0x2a0d, busstop 0x2f17, custom lift-gate
> > 0x6905)
> > 
> > 
> > 
> > On the cmd line
> > 
> > --nearby-poi-rules=*/unnamed:100:delete-poi,*/named:100:delete-poi
> > 
> > 
> > 
> > On my densed big city area (Antwerpen) In that case I expect maybe
> > a
> > couple of thousand benches, trees and bicycle parkings disappear
> > which do not.
> > 
> > 
> > 
> > Can I help testing better by increasing some logging? How could I
> > do
> > that?
> > 
> > 
> > 
> > Kind regards, joris
> > 
> > 
> > 
> > Silo’s (0x2a19) don’t disappear / N51° 11.992' E4° 24.916'
> > 
> > An occasional lift gate (0x6905) does disappear
> > 
> > [cid:image001.jpg@01D622B7.BA7DE260]
> > 
> > 
> > 
> > Bicycle stands (0x2f18): don’t disappear
> > 
> > N51° 13.685' E4° 24.281'
> > 
> > [cid:image002.jpg@01D622B7.BA7DE260]
> > 
> > 
> > 
> > 
> > 
> > -Oorspronkelijk bericht-
> > Van: mkgmap-dev  Namens
> > Ticker Berkin
> > Verzonden: maandag 4 mei 2020 16:13
> > Aan: mkgmap development 
> > Onderwerp: Re: [mkgmap-dev] nearby POIs
> > 
> > 
> > 
> > Hi Mike
> > 
> > 
> > 
> > No, I just have --nearby-poi-rules=0x6605:30
> > 
> > 
> > 
> > Gerd has explained why I see a message from NearbyPoiHandler about
> > a
> > POI for that wasn't 0x6605 - the logging of the removal of an exact
> > duplicate has moved from StyledConverter
> > 
> > 
> > 
> > Ticker
> > 
> > 
> > 
> > On Mon, 2020-05-04 at 14:35 +0100, Mike Baggaley wrote:
> > 
> > > Hi Ticker, have you got a --nearby-poi-rules-config option as
> > > well?
> > 
> > > 
> > 
> > > Cheers,
> > 
> > > Mike
> > 
> > > 
> > 
> > > -Original Message-
> > 
> > > From: Ticker Berkin [mailto:rwb-mkg...@jagit.co.uk]
> > 
> > > Sent: 04 May 2020 11:33
> > 
> > > To: Development list for mkgmap  > > ai
> > > lto:mkgmap-dev@lists.mkgmap.org.uk>>
> > 
> > > Subject: Re: [mkgmap-dev] nearby POIs
> > 
> > > 
> > 
> > > OK, looking up the # as a way instead gives a polygon that
> > > matches
> > > the
> > 
> > > description and would generate a typ code as per the message
> > 
> > > 
> > 
> > > I was more worried about it logging messages about POI with typ
> > > codes
> > 
> > > that I hadn't mentioned in rules and not saying

Re: [mkgmap-dev] nearby POIs

[Ticker Berkin]

Hi Gerd

I missed this. I looked at the footway from the gate and it had the
expected gate. The other gate is on the edge of the park polygon!

Ticker

On Tue, 2020-05-05 at 16:18 +, Gerd Petermann wrote:
> Hi Ticker,
> 
> the node http://www.openstreetmap.org/node/2038594304 is really
> duplicated, see http://www.openstreetmap.org/node/5364865281
> 
> Anyway, it might be a good special case to check if routing works.
> 
> Gerd
> 
> 
> Von: mkgmap-dev  im Auftrag
> von Ticker Berkin 
> Gesendet: Dienstag, 5. Mai 2020 17:15
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] nearby POIs
> 
> Hi
> 
> In my sample I got 3 POIs removed with codes I didn't specify.
> Two of these were duplicate areas in OSM and last was
> 
> INFO: uk.me.parabola.mkgmap.osmstyle.NearbyPoiHandler
>  ../mapHants/74210001.osm.pbf: Removed duplicate POI with type 0x3200
> gate for element http://www.openstreetmap.org/node/2038594304
> 
> which is a {barrier=gate,bicycle=yes,motor_vehicle=private} on a
> footway. Maybe the footway is split at the gate to handle access
> and/or
> mkgmap:road-speed and the POI gets duplicated.
> 
> Anyway, none of these indicate a problem.
> 
> Ticker
> 
> On Tue, 2020-05-05 at 11:03 +0100, Ticker Berkin wrote:
> > Hi Gerd
> > 
> > That got rid of my multiple benches.
> > 
> > Just looking at the log for the few other POI it also got rid of.
> > 
> > It would be useful for the log message to include the distance
> > between
> > the POIs
> > 
> > Ticker
> > 
> > On Tue, 2020-05-05 at 09:19 +, Gerd Petermann wrote:
> > > Hi all,
> > > 
> > > attached is a patch that seems to work. I've kept the logging as
> > > memory is not such a big problem.
> > > I've not yet tested special cases like duplicated barrier nodes
> > > or
> > > a
> > > group of nodes where only some are within the tile boundary.
> > > 
> > > Please check if your problems are solved with this version, a
> > > binary
> > > is here:
> > > http://files.mkgmap.org.uk/download/469/mkgmap.jar
> > > 
> > > Gerd
> > > 
> > > 
> > > Von: mkgmap-dev  im
> > > Auftrag
> > > von Joris Bo 
> > > Gesendet: Dienstag, 5. Mai 2020 08:32
> > > An: Development list for mkgmap
> > > Betreff: Re: [mkgmap-dev] nearby POIs
> > > 
> > > Hi,
> > > 
> > > 
> > > 
> > > I have been testing the nearby poi rules as well with 4485
> > > 
> > > A while I struggled thinking misconfiguration because I see
> > > nothing
> > > happening but then after extending the ranges, an occasional poi
> > > disappears. (toilet 0x2a0d, busstop 0x2f17, custom lift-gate
> > > 0x6905)
> > > 
> > > 
> > > 
> > > On the cmd line
> > > 
> > > --nearby-poi-rules=*/unnamed:100:delete-poi,*/named:100:delete
> > > -poi
> > > 
> > > 
> > > 
> > > On my densed big city area (Antwerpen) In that case I expect
> > > maybe
> > > a
> > > couple of thousand benches, trees and bicycle parkings disappear
> > > which do not.
> > > 
> > > 
> > > 
> > > Can I help testing better by increasing some logging? How could I
> > > do
> > > that?
> > > 
> > > 
> > > 
> > > Kind regards, joris
> > > 
> > > 
> > > 
> > > Silo’s (0x2a19) don’t disappear / N51° 11.992' E4° 24.916'
> > > 
> > > An occasional lift gate (0x6905) does disappear
> > > 
> > > [cid:image001.jpg@01D622B7.BA7DE260]
> > > 
> > > 
> > > 
> > > Bicycle stands (0x2f18): don’t disappear
> > > 
> > > N51° 13.685' E4° 24.281'
> > > 
> > > [cid:image002.jpg@01D622B7.BA7DE260]
> > > 
> > > 
> > > 
> > > 
> > > 
> > > -Oorspronkelijk bericht-
> > > Van: mkgmap-dev  Namens
> > > Ticker Berkin
> > > Verzonden: maandag 4 mei 2020 16:13
> > > Aan: mkgmap development 
> > > Onderwerp: Re: [mkgmap-dev] nearby POIs
> > > 
> > > 
> > > 
> > > Hi Mike
> > > 
> > > 
> > > 
> > > No, I just have --nearby-poi-rules=0x6605:30
> > > 
> > > 
> > > 
> > > Gerd has explain

Re: [mkgmap-dev] nearby POIs

[Ticker Berkin]

Hi Gerd & Mike

I'd be concerned if this logic can move or delete [barrier=...] and
[highway=...] points that share nodes with ways. There are two aspects:
First, if --link-pois-to-ways then any access/speed restrictions should
still take place. Second is the presentation regardless of the -
-link... option, it will just look wrong and confusing and I agree with
Gerd's warning about having a wildcard rule.

Concerning the handling of named/unnamed and delete/merge:
I'd like to see a method that deletes all unnamed POI within {distance}
of a named one.

Also, I'd suggest interpreting the rules strictly in the defined order,
although I realise this doesn't quite make sense because named/unnamed
points might match different rules. I haven't explained this very well.

Ticker

On Wed, 2020-05-06 at 06:44 +, Gerd Petermann wrote:
> Hi all,
> 
> thinking again about "Known problems:  The new implementation will
> not work well for the /all case because a group with different names
> is not detected as such"
> it is probably not a problem of the algo but of the docu.
> I can't think of any reason to remove a POI with a given type x named
> "abc" when it is close to another POI with the same type named "xyz"
> or when one of them is unnamed, the implementation is probably
> exactly what is wanted.
> So, I think I should simply add the mentioned grouping by type & name
> to the documentaion?
> I think we should define what happens when multiple rules match the
> same type.
> These 3 rules all match for a POI 0x3205 with name "Test" but it is
> not obvious which one will be used.
> 0x3205:30:merge-at-mid-point
> 0x3203-0x3207/named:20:delete-name
> 0x3200-0x331f:50
> 
> With the current code the last one is used because of some internal
> sorting, probably not what was intended by the user.
> I see no obvious way to handle this. What should happen?
> 
> BTW: I didn't try but I think default rules (*) with a radius > 5m
> are quite dangerous. Traffic lights or barriers may disappear. Also
> when you reander natural=tree
> POI you probably don't want to remove most of them. So, if you use
> them make sure that you specify rules for everything that should not
> be removed.
> 
> Gerd
> 
> 
> Von: mkgmap-dev  im Auftrag
> von Gerd Petermann 
> Gesendet: Mittwoch, 6. Mai 2020 07:04
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] nearby POIs
> 
> Hi all,
> 
> thanks for testing. I've just noticed that the jar file contained a
> modified points file, but I guess you all used your own style files.
> I thought about the possible effects on routing and found none.
> 
> The new algo works like this:
> 1) Collect all generated POI and the corresponding nodes before
> adding them to the map
> 2) after all style rules were processed and WrongAngleFixer has moved
> points (and POI) to fix visible wrong angles the POI are
> deduplicated.
> This means they are
>  - grouped by type and name
>  - each group is processed so that
>+ the first matching rule is applied using the given radius:
> Iterate as long as there are multiple POI
>  * for each POI, build a group of all nearby POI
>  * select the biggest group
>  * calculate the center of that group
>  * select the POI that is closest to the center
>  * apply the action to the other POI of the group, maybe move the
> selected POI to the middle
>  * remove all POI handled in this group
> 
> Known problems:
> - The new implementation will not work well for the /all case because
> a group with different names is not detected as such
>  - maybe identical POI are not removed with the delete-name case
> - Maybe there is an unwanted effect on rendering when WrongAngleFixer
> moves a point and the corresponding POI is not moved. This already
> happens sometimes and should be no big problem.
> 
> If I find no solution for the first 2 problems today I'll revert
> trunk version and create a branch for further development.
> 
> Gerd
> 
> 
> Von: mkgmap-dev  im Auftrag
> von Ticker Berkin 
> Gesendet: Dienstag, 5. Mai 2020 12:03
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] nearby POIs
> 
> Hi Gerd
> 
> That got rid of my multiple benches.
> 
> Just looking at the log for the few other POI it also got rid of.
> 
> It would be useful for the log message to include the distance
> between
> the POIs
> 
> Ticker
> 
> On Tue, 2020-05-05 at 09:19 +, Gerd Petermann wrote:
> > Hi all,
> > 
> > attached is a patch that seems to work. I've kept t

Re: [mkgmap-dev] nearby-POI: What to do with several POI arranged on a circle?

[Ticker Berkin]

Hi

The problem is in the point grouping algo, rather than anything to do
with the merge-at-mid-point option.

Although an interesting problem to solve, it seems to be getting
excessive. The simple logic in the last versions seemed to solve most
users's problems and make them happy.

Ticker


On Thu, 2020-05-07 at 07:42 +, Gerd Petermann wrote:
> Hi all,
> 
> while doing further tests I've found this edge case (see attached
> file)
> Draw a circle with a diameter of ~56m and tag all nodes amenity=bank.
> The default style has 
> amenity=bank [0x2f06 resolution 24]
> 
> With --nearby-poi-rules=0x2f06:30:merge-at-mid-point one might expect
> a single POI in the middle of the circle, but the result is
> different:
> Since there is no POI near the center of the circle the current algo
> finds 4 groups, all close to the edge of the circle.
> 
> I think for merge-at-mid-point I need a different algo. I'm looking
> at https://en.wikipedia.org/wiki/Cluster_analysis now.
> 
> Gerd
> 
> 
> 
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] nearby-POI: What to do with several POI arranged on a circle?

[Ticker Berkin]

Hi Gerd

The bench in lake problem is avoided by the user not using the merge-at
-mid-point option. Possibly making the delete-poi option keep the most
central one and delete the rest.

Ticker 

On Thu, 2020-05-07 at 09:12 +, Gerd Petermann wrote:
> Hi Ticker,
> 
> I should have used amenity=bench in the example, this is a bit more
> realistic, but the default style doesn't generate a POI for that.
> 
> I've found a rather simple iterative algo to fix the problem, but
> what I really wanted to point out is that the result can look really
> wrong.
> Benches are often arranged around something, e.g. a small lake/pond.
> I think nobody wants a map that shows a bench in the middle of a
> lake.
> OTHO, bus stops typically come in pairs, but maybe 50m apart. It
> seems reasonable to merge them in the middle.
> 
> Gerd
> 
> ________
> Von: mkgmap-dev  im Auftrag
> von Ticker Berkin 
> Gesendet: Donnerstag, 7. Mai 2020 10:21
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] nearby-POI: What to do with several POI
> arranged on a circle?
> 
> Hi
> 
> The problem is in the point grouping algo, rather than anything to do
> with the merge-at-mid-point option.
> 
> Although an interesting problem to solve, it seems to be getting
> excessive. The simple logic in the last versions seemed to solve most
> users's problems and make them happy.
> 
> Ticker
> 
> 
> On Thu, 2020-05-07 at 07:42 +, Gerd Petermann wrote:
> > Hi all,
> > 
> > while doing further tests I've found this edge case (see attached
> > file)
> > Draw a circle with a diameter of ~56m and tag all nodes
> > amenity=bank.
> > The default style has
> > amenity=bank [0x2f06 resolution 24]
> > 
> > With --nearby-poi-rules=0x2f06:30:merge-at-mid-point one might
> > expect
> > a single POI in the middle of the circle, but the result is
> > different:
> > Since there is no POI near the center of the circle the current
> > algo
> > finds 4 groups, all close to the edge of the circle.
> > 
> > I think for merge-at-mid-point I need a different algo. I'm looking
> > at https://en.wikipedia.org/wiki/Cluster_analysis now.
> > 
> > Gerd
> > 
> > 
> > 
> > ___
> > mkgmap-dev mailing list
> > mkgmap-dev@lists.mkgmap.org.uk
> > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] nearby-POI: named / unnamed

[Ticker Berkin]

Hi Gerd

I was considering this mostly from the point-of-view of searching, with
map declutter a secondary consideration.

I was assuming that a rule has gathered a cloud of POI with the same
type/subtype that had resolved as "nearby" somehow.

Then some action clause on the rule to is used to guide the following
possible actions:

- If none are named: find a central one to keep and delete the others

- If any named, keep the name on the central for each distinct name and
un-name the rest

- If one is named: keep this and delete the unnamed

- If any are named, keep these and delete the unnamed

- If multiple with the same name, keep the central one for each
distinct name and delete the rest, including unnamed.

I think this should all be done after the style has been interpreted
and act on the resultant POI. I don't like the idea of new mkgmap tags
to control the interpretation.

In the case you mention where barrier POI, using the same type/subtype
are given a name to indicate the barrier type, it is entirely up to a
matching rule as to how it should be handled (see above). 

Another rule clause could be string that is appended to the POI name
with a substitution for the number deleted, eg
--nearby-poi-rules=0x6605:30:delete-poi:"{numdel} others within 30
metres"

As has been said earlier, the new is_in() function is good for avoiding
the initial generation of some POI, but it can't do the full job.
For
instance, 'points' could contain:
  tourism=picnic_site [0x4a00
resolution 24]
  leisure=picnic_table &
is_in(tourism,picnic_site,in_or_on)=false
 [0x4a00 resolution 24]
but
a mechanism to suppress 0x4a00 for multiple tables not in a picnic site
is still needed.

Ticker

On Fri, 2020-05-08 at 05:30 +, Gerd Petermann wrote:
> Hi all,
> 
> in (1) Ticker suggested "I'd like to see a method that deletes all
> unnamed POI within {distance}
> of a named one. 
> I guess this is also close to the meaning of "declutter" (I don't
> know how that works in Garmin devices, my Oregon doesn't have such an
> option)
> 
> I don't fully understand the idea. I assume it is about overlapping
> icons?
> @Ticker: Should this be done for a given list of POI types or for all
> named POI? The default style often adds names to POI, e.g. for a
> barrier=bollard. 
> Is this the name of the POI? An alternative would be to use the
> name=* tag of the corresponding node. Or we could introduce a new tag
> mkgmap:treat-as-unnamed=true which could be used in the style to mark
> generated names.
> Should it be done before or after the existing rules were applied?
> Remember that we have the "delete-name" action.
> 
> Gerd 
> 
> (1) http://gis.19327.n8.nabble.com/nearby-POIs-tp5964757p5964995.html
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Missing osm tags in the echo output

[Ticker Berkin]

Hi Joris

Mkgmap ignores tags in the OSM source that are not referenced by style
rules or are needed by explicit code.

You can add to the list of tags read by adding line to style/options,
eg:
...
extra-used-tags=direction
...

Ticker

On Fri, 2020-05-15 at 12:46 +, Joris Bo wrote:
> Hello,
>  
> When debugging my map I encountered missing tags in the echotags
> output which are available at openstreetmap.org
> And also in the geofabric download because after assigning the tag to
> a variable in my style and after that call the echotags statement
> they do appear in the output.
> So I was thinking that mkgmap will only echo a part of the tags and
> not just ‘all’? Can i do something about this behavior?
> Kind regards
> Joris
>  
>  
> Met vriendelijke groet,
>  
> Joris Bovens
> +31 6 53233898
> jori...@hotmail.com
>  
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev