date:20131101

Re: [mkgmap-dev] [Patch v1] avoid wrong bearing results

2013-11-01 Thread Gerd Petermann

Hi Marko,

> >the patch (this v1) is only meant to solve routing problems caused by 
> >rounding I don't think that it has an influence on SeaGenerator.
> 
> Right, I was too optimistic, hoping that this would fix the bogus 
> warnings in SeaGenerator too.

Maybe it is possible to use the higher precision for this as well.
I assume we just have to use it when converting to 
java areas in Java2DConverter.

> 
> The patch (or some other change since r2795) did make 2 of 4 warnings 
> for roundabout flare roads go away. Only the following remained:
> 
> 2013/10/31 21:17:17 WARNING (StyledConverter): 63240002.osm.pbf: 
> Roundabout segment 35062431 direction looks wrong (see 
> http://www.openstreetmap.org/?mlat=60.23825&mlon=24.88777&zoom=17)
> 2013/10/31 21:17:18 WARNING (StyledConverter): 63240002.osm.pbf: 
> Roundabout segment 34151581 direction looks wrong (see 
> http://www.openstreetmap.org/?mlat=60.23242&mlon=24.95879&zoom=17)
> 2013/10/31 21:17:37 WARNING (RouteNode): 63240005.osm.pbf: Outgoing 
> roundabout flare road (4;9;13;23 Vaajakoskentie, 
> http://www.openstreetmap.org/browse/way/221616945) points in wrong 
> direction?  
> http://www.openstreetmap.org/?mlat=62.24637&mlon=25.87302&zoom=17
> 
> Both roundabout segments are in micro-mapped roundabouts that have been 
> split because of route relations.
> 
> I reverted your patch and reran with today's dump. I got again the usual 
> 5 roundabout warnings (2 more about flare roads) than the above. So, 
> your patch is making a positive difference there.

OK, that's what I expected :-)
As I said, the patch was a quick hack, I just wanted to demonstrate that
we only have to change a few lines to store the higher precision,
and it will not cost more memory.

> 
> >Do you have a reason for not using precompiled sea?
> 
> Yes. I mainly use mkgmap as a validator, and I am routinely fixing 
> errors in finland.osm.pbf. The sea polygons are not severely broken that 
> often, it is usually just anti-islands.  Only about once per month I 
> have to fire up JOSM with an Osmosis-made extract of natural=coastline 
> to see what is wrong.
> 
OK, I see. I'll try with the same data to check what can be changed.

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

Re: [mkgmap-dev] [Patch v1] avoid wrong bearing results

2013-11-01 Thread WanMil


Hi Marko,

I think the SeaGenerator might be improved by using higher precision 
coordinates. But since the precompiled sea option is available I will 
not put any more effort into the "old" algorithms.


WanMil



On Thu, Oct 31, 2013 at 10:44:31PM +0100, Gerd Petermann wrote:

the patch (this v1) is only meant to solve routing problems caused by
rounding I don't think that it has an influence on SeaGenerator.


Right, I was too optimistic, hoping that this would fix the bogus
warnings in SeaGenerator too.

The patch (or some other change since r2795) did make 2 of 4 warnings
for roundabout flare roads go away. Only the following remained:

2013/10/31 21:17:17 WARNING (StyledConverter): 63240002.osm.pbf:
Roundabout segment 35062431 direction looks wrong (see
http://www.openstreetmap.org/?mlat=60.23825&mlon=24.88777&zoom=17)
2013/10/31 21:17:18 WARNING (StyledConverter): 63240002.osm.pbf:
Roundabout segment 34151581 direction looks wrong (see
http://www.openstreetmap.org/?mlat=60.23242&mlon=24.95879&zoom=17)
2013/10/31 21:17:37 WARNING (RouteNode): 63240005.osm.pbf: Outgoing
roundabout flare road (4;9;13;23 Vaajakoskentie,
http://www.openstreetmap.org/browse/way/221616945) points in wrong
direction?
http://www.openstreetmap.org/?mlat=62.24637&mlon=25.87302&zoom=17

Both roundabout segments are in micro-mapped roundabouts that have been
split because of route relations.

I reverted your patch and reran with today's dump. I got again the usual
5 roundabout warnings (2 more about flare roads) than the above. So,
your patch is making a positive difference there.


Do you have a reason for not using precompiled sea?


Yes. I mainly use mkgmap as a validator, and I am routinely fixing
errors in finland.osm.pbf. The sea polygons are not severely broken that
often, it is usually just anti-islands.  Only about once per month I
have to fire up JOSM with an Osmosis-made extract of natural=coastline
to see what is wrong.

Best regards,

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


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

Re: [mkgmap-dev] [Patch v1] avoid wrong bearing results

2013-11-01 Thread WanMil


Hi Gerd,

well done!
I like the way that the higher precision can be used step by step and we 
don't have to change the whole source code at once!


Does the change require more memory? I have seen two new byte fields in 
the Coord class.


WanMil


Hi,

a few weeks ago I suggested that we might need higher precision in the
Coord class.

Attached patch is a quick hack to implement this.
If I got it right, this may allow to remove a lot
of code that tries to correct what the rounding had
done wrong. For the beginning, I've used the
precise values only for bearing calculations,
as I think that this is most important.

high_precision_coord_v1.patch


Please let me know what you think about it.

Gerd



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

Re: [mkgmap-dev] [Patch v1] avoid wrong bearing results

2013-11-01 Thread Gerd Petermann

Hi WanMil,

> well done!
> I like the way that the higher precision can be used step by step and we 
> don't have to change the whole source code at once!

yes, that's why I liked it so much that I posted the quick hack.
The next step might be to use it in Java2DConverter and routines like
Way.clockwise().
It might also be used to beautify roundabouts and other zig-zagging
caused by rounding errors. 

> 
> Does the change require more memory? I have seen two new byte fields in 
> the Coord class.

no, it uses two spare bytes (a Coord instance allocates 16 bytes (8 byte 
alignment)
with the patch 12 bytes are used, still leaving 4 spare bytes)

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

[mkgmap-dev] [Patch v2] higher precision in coordinates

2013-11-01 Thread Gerd Petermann

Hi,

attached is v2 of the patch.
It still only solves problems related to routing,
but I see many possible improvemets with
more coding.
I think we should create a branch for it, but I first like 
to finish work on the reduce_limits branch, which 
in turn is more useful in combination with the 
mergeroads branch.

Gerd



  

high_precision_coord_v2.patch
Description: Binary data
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] Numerical comparison of two tags

2013-11-01 Thread Bernhard Hiller

I'd like to set maxspeed to the minimum of maxspeed, maxspeed:forward, 
and maxspeed:backward.

In my lines file, I use:

|maxspeed:forward=*&  maxspeed!=* { set maxspeed='${maxspeed:forward}' }
maxspeed:forward=*&  (maxspeed:forwardThat works only if exactly one tag is set. But when both forward and 
backward are available, I get the value of forward even if backward is 
less. An example is wayhttp://www.openstreetmap.org/browse/way/70594951.


I played with additional / different rules, and my conclusion is that it 
is NOT POSSIBLE to compare the values of two tags with each other.


For example, I tried:

|highway=*&  maxspeed!=* { set maxspeed=999 }
maxspeed:forward=*&  (maxspeed:forwardAnd you can guess the result: maxspeed=999, for that way with 
maxspeed:forward=60 and maxspeed:backward=40.


Is my conclusion correct?
And, if so, will there be a patch?
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] [PATCH v2] finalizer style file

2013-11-01 Thread WanMil


The finalizer rules are now defined in each style file.

The rules start after the finalize section marker:


@Steve: Please have a look on the patch. I think it is cleanly 
integrated in the current implementation without too much hacking ;-) I 
haven't implemented tests yet so it's not well tested. But my first 
tests seemed to work well.


WanMil



Hi WanMil


I had a look how much effort it is to add a finalizer style file that is
used each time a rule with an element type definition matches. This
might make it more easy to implement "general rules" (like the
mkgmap:access tag which seems to be useful for complex styles). The
finalize file must contain actions only. Otherwise mkgmap stops with an
error message.


This is interesting, early on I though that access rules would have
to be in a separate file and this might be it.

It also fits in with something else that I want to do, which is
to remove all the other getTag() calls from StyledConverter.


@Steve: do you think it would be possible to add a finalize section to
the bottom of each style file (especially points, lines and polygons)? I
have the feeling that this is more understandable and maybe better to
have different finalize styles for each element type.


Sounds like a good idea, I can't think of a syntax for it I like just
yet though.  You could also have different files lines_final,
points_final etc.

..Steve


Index: resources/styles/default/points
===
--- resources/styles/default/points	(revision 2795)
+++ resources/styles/default/points	(working copy)
@@ -8,8 +8,6 @@
 # and http://wiki.openstreetmap.org/wiki/Mkgmap/help/Custom_styles
 # for more information.
 
-include 'inc/address';
-
 barrier=bollard | barrier=bus_trap
 { add mkgmap:bicycle='${bicycle|subst:private=>no|def:yes}'; add mkgmap:foot='${foot|subst:private=>no|def:yes}'; addaccess no }
 barrier=block | barrier=cycle_barrier | barrier=stile | barrier=kissing_gate
@@ -273,3 +271,8 @@
 
 include 'inc/water_points';
 include 'inc/landuse_points';
+
+
+# The finalizer section is executed for each element when a rule with an element type matches
+
+include 'inc/address';
\ No newline at end of file
Index: resources/styles/default/polygons
===
--- resources/styles/default/polygons	(revision 2795)
+++ resources/styles/default/polygons	(working copy)
@@ -8,12 +8,6 @@
 # and http://wiki.openstreetmap.org/wiki/Mkgmap/help/Custom_styles
 # for more information.
 
-# polygons do not have address information in the Garmin map format
-# so as long as the address information is not required in a stlye rule
-# it is not required to include the address rules 
-# include 'inc/address';
-
-
 leisure=* & sport=* & name=* { set name='${name} (${sport})' }
 leisure=* & sport=* & name!=* { add name='${sport}' }
 
@@ -80,3 +74,7 @@
 
 include 'inc/water_polygons';
 include 'inc/landuse_polygons';
+
+
+# The finalizer section is executed for each element when a rule with an element type matches
+
Index: resources/styles/default/lines
===
--- resources/styles/default/lines	(revision 2795)
+++ resources/styles/default/lines	(working copy)
@@ -8,7 +8,6 @@
 # and http://wiki.openstreetmap.org/wiki/Mkgmap/help/Custom_styles
 # for more information.
 
-include 'inc/address';
 include 'inc/refs';
 
 aeroway=runway [0x27 resolution 20]
@@ -192,3 +191,8 @@
 
 include 'inc/water_lines';
 include 'inc/contour_lines';
+
+
+# The finalizer section is executed for each element when a rule with an element type matches
+
+include 'inc/address';
Index: src/uk/me/parabola/mkgmap/osmstyle/function/TypeFunction.java
===
--- src/uk/me/parabola/mkgmap/osmstyle/function/TypeFunction.java	(revision 0)
+++ src/uk/me/parabola/mkgmap/osmstyle/function/TypeFunction.java	(revision 0)
@@ -0,0 +1,53 @@
+/*
+ * Copyright (C) 2013.
+ *
+ * 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.
+ */
+
+package uk.me.parabola.mkgmap.osmstyle.function;
+
+import uk.me.parabola.mkgmap.reader.osm.Element;
+import uk.me.parabola.mkgmap.reader.osm.Node;
+import uk.me.parabola.mkgmap.reader.osm.Relation;
+import uk.me.parabola.mkgmap.reader.osm.Way;
+
+public class TypeFunction extends StyleFunction {
+
+	public TypeFunction() {
+		super(null);
+	}
+
+	public boolean supportsNode() {
+		return true;
+	}
+
+	public boolean supportsWay() {
+		return true;
+	}
+
+	public boolean supportsRelation

Re: [mkgmap-dev] Numerical comparison of two tags

2013-11-01 Thread Henning Scholland

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Bernd,
did you tried something like:

maxspeed:forward < '${maxspeed}' ?

Henning
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (MingW32)

iQEcBAEBAgAGBQJSdAbRAAoJEPFgsWC7jOeTwkAH/38JgeX1wG//YX3LA3k0edzT
csc6jjOdvytbLg6eatKZlPc4FA47jkNVvD4RWaPo7Peab9HKsJhUQ1Q03tYR55Dy
ca0QhOiQFV/ja8N3f861HkmOU8VLmAlL0fnTeyusijGupS6gfIZUpbwmhehZyOL1
3yO1KPX2iOTxFyL9r0IL80bX8E7svkDDiEfsQeKIfb4u/Zg9IXNo3LQJ+wRVuVao
MfeEAFTIH/2U0rWBfoH2YOOOGHykdvn7QkemgZFOFXBagYqv6NGND0zWGjHMHtqP
PtPT/5WaJfSVmr5a81cewWF+q7cS2ogjNE/FJc2jOsSUM8TnOoZxLiQdqfduT8s=
=OYq9
-END PGP SIGNATURE-

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

Re: [mkgmap-dev] Numerical comparison of two tags

2013-11-01 Thread Steve Ratcliffe


On 01/11/13 12:50, Bernhard Hiller wrote:

it is NOT POSSIBLE to compare the values of two tags with each other.


That is correct.

But it is now an easy thing to implement.  There are a few syntaxes
we could use such as:

  maxspeed < get_tag(maxspeed:forward)
  maxspeed < ${maxspeed:forward}

The attached patch implements the dollar notation. So the first part of 
your example could be written as:


  maxspeed:forward=* & maxspeed!=* { set maxspeed='${maxspeed:forward}' }
  maxspeed:forward=* & maxspeed:forward < ${maxspeed}
{ set maxspeed='${maxspeed:forward}' }

Note there are no quotes around ${maxspeed}.

It's not limited to numeric comparisons, you could have:
  name != $name_int

Currently you can't just have one of these by itself, it has
to have another test first. I'm pretty sure that can be fixed, but
that's one for later.

(built jar: http://files.mkgmap.org.uk/download/161/mkgmap.jar)

..Steve
Index: src/uk/me/parabola/mkgmap/osmstyle/eval/ExpressionReader.java
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===
--- src/uk/me/parabola/mkgmap/osmstyle/eval/ExpressionReader.java	(revision 2795)
+++ src/uk/me/parabola/mkgmap/osmstyle/eval/ExpressionReader.java	(revision )
@@ -45,15 +45,30 @@
 break;
 
 			WordInfo wordInfo = scanner.nextWordWithInfo();
-			if (isOperation(wordInfo))
+			if (isOperation(wordInfo)) {
+//System.out.println("saveOp" + wordInfo.getText());
 saveOp(wordInfo.getText());
-			else if (scanner.checkToken("(")) {
+			} else if (wordInfo.isQuoted()) {
+//System.out.println("quoted: " + wordInfo.getText());
+pushValue(wordInfo.getText());
+			} else if (wordInfo.getText().charAt(0) == '$') {
+//System.out.println("FOO " + wordInfo.getText());
+String s = scanner.nextWord();
+//System.out.println("next " + s);
+if (s.equals("{")) {
+	s = scanner.nextWord();
+	//System.out.println("got " + s);
+	scanner.validateNext("}");
+}
+stack.push(new GetTagFunction(s));
+			} else if (scanner.checkToken("(")) {
 // it is a function
 // this requires a () after the function name
 scanner.validateNext("(");
 scanner.validateNext(")");
 saveFunction(wordInfo.getText());
 			} else {
+//System.out.println("value: " + wordInfo.getText());
 pushValue(wordInfo.getText());
 			}
 		}
@@ -150,7 +165,7 @@
 			Op arg2 = stack.pop();
 			Op arg1 = stack.pop();
 
-			if (arg1.isType(VALUE) && arg2.isType(VALUE))
+			if (arg1.isType(VALUE) /*&& arg2.isType(VALUE)*/)
 arg1 = new GetTagFunction(arg1.getKeyValue());
 
 			BinaryOp binaryOp = (BinaryOp) op;
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] [Patch v1] avoid wrong bearing results

Re: [mkgmap-dev] [Patch v1] avoid wrong bearing results

Re: [mkgmap-dev] [Patch v1] avoid wrong bearing results

Re: [mkgmap-dev] [Patch v1] avoid wrong bearing results

[mkgmap-dev] [Patch v2] higher precision in coordinates

[mkgmap-dev] Numerical comparison of two tags

[mkgmap-dev] [PATCH v2] finalizer style file

Re: [mkgmap-dev] Numerical comparison of two tags

Re: [mkgmap-dev] Numerical comparison of two tags

9 matches

Site Navigation

Mail list logo

Footer information