Re: [mkgmap-dev] Help from the style file gurus
Felix Hartmann escribió: You are using types that Mapsource does not display. As simple. 0x2b is the last line type Mapsource is using. GPS works to 0x3f. You have to use extended (5 digit) types instead. Great! At last I can have bridges on my maps. I've used 0x10600-2 and they show both on 6.13.7 and 6.15.6, but they are much better rendered on 6.13.7. On 6.15.6 they appear too thin and a bit difficult to see. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Help from the style file gurus
On 21.01.2010 11:00, Carlos Dávila wrote: Felix Hartmann escribió: You are using types that Mapsource does not display. As simple. 0x2b is the last line type Mapsource is using. GPS works to 0x3f. You have to use extended (5 digit) types instead. Great! At last I can have bridges on my maps. I've used 0x10600-2 and they show both on 6.13.7 and 6.15.6, but they are much better rendered on 6.13.7. On 6.15.6 they appear too thin and a bit difficult to see. Ups, don't use 6.15.6, but update to 6.15.7. 6.15.6 is complete junk when it comes to layout. ___ 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] Help from the style file gurus
Felix Hartmann escribió: On 21.01.2010 11:00, Carlos Dávila wrote: Felix Hartmann escribió: You are using types that Mapsource does not display. As simple. 0x2b is the last line type Mapsource is using. GPS works to 0x3f. You have to use extended (5 digit) types instead. Great! At last I can have bridges on my maps. I've used 0x10600-2 and they show both on 6.13.7 and 6.15.6, but they are much better rendered on 6.13.7. On 6.15.6 they appear too thin and a bit difficult to see. Ups, don't use 6.15.6, but update to 6.15.7. 6.15.6 is complete junk when it comes to layout. Updated. Thanks, you are always sharing good information. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Question on license for style-file
Felix Hartmann schrieb am 21.01.2010 02:31: I already had quite a few ideas/concepts copied by Garmin map compilers (e.g. using assymetric transparent lines - which was so forgotten by Garmin or not intended that they stopped supporting it until copying many parts for the Garmin Transalpin - if you look at their typfile it really shows many traces of the typfiles I used when starting my then called mtb maps on the osm wiki, or first versions of my openmtbmap.). I can't really understand your problem. For once, in my the eyes the ideas/concepts your are mentioning not so groundbraking, that nobody else is able to think of them. (Today they might still be good enough for a patent :-) I really admit your work, but i think the greatest part is not getting the ideas but getting everything done. So I would not say that somebody copied your ideas/concepts, i would rather say that they were inspired by your work. Above you write, that some of your concepts were forgotten by Garmin. So actually you are also copying their ideas :-) And as a second point, why do you worry about someone copying your work as closed source? It is certainly not nice, but is it really a problem? If you give away your maps for free (free beer as well as really free), what would change, if Garmin would sell identical maps for money? They will make some money, but you will not loose any money. I do not care if anybody earns some money with the aid of my free contributions, as long as my work is still available for free to other people. It migth look different, if you want to earn some money yourself with your maps. But then the problem would not be, to stop other companies yousing your work in a closed source manner, but to stop other people using your work at all. By the way, I think you could earn some money (not much but at least some), if you would sell ready to use flash-cards with your maps on ebay. You could sell them with the recquired free-to-copy license, since most buyers wouldn't bother about copying, if they could by an actual map for perhaps 10 or 15EUR. Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] oneway=reverse handling broken.
Felix Hartmann schrieb am 21.01.2010 13:51: This has come since the latest additions to the style-file rules. And once again I plead for a resurrection of the style branch, so that we can clean-up the style handling of mkgmap. Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] oneway=reverse handling broken.
Hi And once again I plead for a resurrection of the style branch, so that we can clean-up the style handling of mkgmap. OK I shall start on it very soon. I'm sure it will conflict a lot with the 'continue' patch that was added to the trunk, so that will have to be sorted out. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] oneway=reverse handling broken.
On 21.01.2010 18:26, Steve Ratcliffe wrote: Hi And once again I plead for a resurrection of the style branch, so that we can clean-up the style handling of mkgmap. OK I shall start on it very soon. I'm sure it will conflict a lot with the 'continue' patch that was added to the trunk, so that will have to be sorted out. ..Steve Wouldn't it be enough for everyone to create rules like condition blablabla [continue with_actions] Not that no 0x* is included here. This would be simple and effective (and I can't think of any reason why we would need the style branch then). ___ 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] oneway=reverse handling broken.
On 21/01/10 17:28, Felix Hartmann wrote: Not that no 0x* is included here. This would be simple and effective (and I can't think of any reason why we would need the style branch then). We need the style branch because the trunk just doesn't work in a consistent and predictable way. I know that by adding lots of extra rules you can get almost anything to work, but you shouldn't have to do that. Perhaps the patch that was applied fixed some things and I will investigate fully before doing anything. I could never understand exactly what problems you had with the style branch, but I am sure that they can be easily overcome once I have good examples to work with. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Fake warnings in log
Since yesterday the number of similar arcs warnings has increased very much, but when you look at the supposed wrong data, they are correct and there are no recent changes. May be recent commits have introduced some bug in this regard. You can have a look at this one for example: 2010/01/21 09:14:35 ADVERTENCIA (RouteNode): Similar arcs ((N-630 Carretera de Gijón a Sevilla, http://www.openstreetmap.org/browse/way/34954325) and (N-630 Carretera de Gijón a Sevilla, http://www.openstreetmap.org/browse/way/34954325)) from http://www.openstreetmap.org/?mlat=38.32804mlon=-6.32094zoom=17 Regards, Carlos ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Fake warnings in log
Carlos Dávila escribió: Since yesterday Sorry, it was day before yesterday when it started to happen, so mp merge may be related. the number of similar arcs warnings has increased very much, but when you look at the supposed wrong data, they are correct and there are no recent changes. May be recent commits have introduced some bug in this regard. You can have a look at this one for example: 2010/01/21 09:14:35 ADVERTENCIA (RouteNode): Similar arcs ((N-630 Carretera de Gijón a Sevilla, http://www.openstreetmap.org/browse/way/34954325) and (N-630 Carretera de Gijón a Sevilla, http://www.openstreetmap.org/browse/way/34954325)) from http://www.openstreetmap.org/?mlat=38.32804mlon=-6.32094zoom=17 Regards, Carlos ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] oneway=reverse handling broken.
Steve Ratcliffe schrieb am 21.01.2010 18:26: OK I shall start on it very soon. That's great news for me, Steve. Thanks! Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Fake warnings in log
Carlos Dávila escribió: Since yesterday Sorry, it was day before yesterday when it started to happen, so mp merge may be related. the number of similar arcs warnings has increased very much, but when you look at the supposed wrong data, they are correct and there are no recent changes. May be recent commits have introduced some bug in this regard. You can have a look at this one for example: 2010/01/21 09:14:35 ADVERTENCIA (RouteNode): Similar arcs ((N-630 Carretera de Gijón a Sevilla, http://www.openstreetmap.org/browse/way/34954325) and (N-630 Carretera de Gijón a Sevilla, http://www.openstreetmap.org/browse/way/34954325)) from http://www.openstreetmap.org/?mlat=38.32804mlon=-6.32094zoom=17 Regards, Carlos I don't know what an arc warning is. But I can say something about the mp code. The mp code should not modify any original way from OSM. The posted warnings link to original OSM ways so mp should not be the reason. WanMil ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Fake warnings in log
Hello Carlos, Since yesterday the number of similar arcs warnings has increased very much, but when you look at the supposed wrong data, they are correct and there are no recent changes. May be recent commits have introduced some bug in this regard. You can have a look at this one for example: 2010/01/21 09:14:35 ADVERTENCIA (RouteNode): Similar arcs ((N-630 Carretera de Gijón a Sevilla, http://www.openstreetmap.org/browse/way/34954325) and (N-630 Carretera de Gijón a Sevilla, http://www.openstreetmap.org/browse/way/34954325)) from http://www.openstreetmap.org/?mlat=38.32804mlon=-6.32094zoom=17 That warning occurs when you have multiple arcs that have the same start and end points and the same length. It could occur when there are duplicate ways in the map data but also it could occur if the style rules you are using generate multiple routable lines from the same way. I notice that in the above message the OSM ids are the same. That implies that you are generating two roads from one way. It's either a bug in mkgmap or in your style rules. Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] oneway=reverse handling broken.
Felix Hartmann schrieb am 21.01.2010 19:07: I wouldn't see (except the strange handling of oneway=reverse - but maybe there is some error on my side) any strange behaviour with the trunk currently. We had quite some topics lately, e.g. that you can not use the same expression twice, or that two independent style rules only worked, when they were arranged in a specific order. Basically I think, that you have fine-tuned your style to the current style handling of the trunk. If there was a problem in the style handling, it was not fixed but you found a way around it. Well continue never worked in any way predictable and my maps were output with half of the lines missing, routing broken,. I guess, this was caused by some of your workarounds, which were based on errors in the trunk's style interpretation. In my experience the style brunch provides every capability of the continue patch, but some of the rules must be rephrased (actually they must be corrected) so that they would work as before. Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] oneway=reverse handling broken.
On 21.01.2010 21:54, Torsten Leistikow wrote: Felix Hartmann schrieb am 21.01.2010 19:07: I wouldn't see (except the strange handling of oneway=reverse - but maybe there is some error on my side) any strange behaviour with the trunk currently. We had quite some topics lately, e.g. that you can not use the same expression twice, or that two independent style rules only worked, when they were arranged in a specific order. That is solved (I spent nearly 10 hours to adapt my style-files that you continue now works endless) Basically I think, that you have fine-tuned your style to the current style handling of the trunk. If there was a problem in the style handling, it was not fixed but you found a way around it. Well continue never worked in any way predictable and my maps were output with half of the lines missing, routing broken,. I guess, this was caused by some of your workarounds, which were based on errors in the trunk's style interpretation. In my experience the style brunch provides every capability of the continue patch, but some of the rules must be rephrased (actually they must be corrected) so that they would work as before. There is besides one bug, I think no more bug inside. The oneway=reverse problem I'm having seems to be related that the street is first set oneway=1 (general open rule), then it is set to oneway=-1 using [continue_withactions], then I want to set it to oneway=1 using plain [continue], and then for the final output it is used again as oneway=1. However maybe I have a typo somewhere when I changed all my rules to adapt to the current behaviour. previously (which was a bug, but I found it quite useful) - on the same highway=primary keya=123 highway=primary [continue] output keya=123 highway=* [continue] OLD no output; NEW output keya=123 [final] output This ment you could write keya=123 as many times as you liked, but it was only output 2 times. Now to achieve the same situation as before one has to keya=123 highway=primary[continue] output keya=123 higwhay=* highway!=primary [continue] no output keya=123 [final] output So you have to build a quite an extensive !=abc list to not output the same lines several times. This now needs a lot of code if you for example want to have 4 different designs for bridges, depending on the width of the way it goes with. On the other hand, multilayered maps are now much easier: highway=motorway [resolution 16-18 0x10100 continue] highway=motorway [resolution 20-22 0x10101 continue] highway=motorway [resolution 24 road_speed=1 road_class=4] is working as intended, without additional code. It's okay, took 10 hours to change all my code so that it fits now with the repaired behaviour (as I use 0x01 for many many roads for routing I already have a lot doubles and it is not easy to keep track where a line is doubled and where not, but the code change of course gave me triples and quadruples of the same way where I only wanted doubles). My only problem is that oneway=reverse handling, I'm not sure if theirs a problem with my style, or if there is some special behaviour related to oneway=reverse that does not occur with oneway=-1 (as in my style I have to change the direction of a way 2-3 times to get the result I want with opposing oneways but also arrows pointing in the direction of traffic). Gruss Torsten ___ 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] [PATCH v2] Major speedup for mp code
Attached patch can be summarized very easy:
* Major speedup for mp code
Please test and commit if no problems arise.
WanMil
Index: src/uk/me/parabola/mkgmap/reader/osm/MultiPolygonRelation.java
===
--- src/uk/me/parabola/mkgmap/reader/osm/MultiPolygonRelation.java
(revision 1505)
+++ src/uk/me/parabola/mkgmap/reader/osm/MultiPolygonRelation.java
(working copy)
@@ -1,9 +1,11 @@
package uk.me.parabola.mkgmap.reader.osm;
-import java.awt.*;
+import java.awt.Polygon;
+import java.awt.Rectangle;
import java.awt.geom.Area;
import java.awt.geom.Line2D;
import java.awt.geom.PathIterator;
+import java.awt.geom.Rectangle2D;
import java.util.ArrayList;
import java.util.Arrays;
import java.util.BitSet;
@@ -337,7 +339,7 @@
log.info(from,
way.getPoints().get(0).toOSMURL());
log.info(to,
way.getPoints().get(way.getPoints().size() - 1)
.toOSMURL());
- // mark this ways as artificially closed
+ // mark this ways as artifically closed
way.closeWayArtificial();
}
}
@@ -357,8 +359,9 @@
JoinedWay tempWay = it.next();
if (tempWay.isClosed() == false) {
if (first) {
- log.warn(
- Cannot join the following ways
to closed polygons. MP-Relation,
+ log
+ .warn(
+ Cannot
join the following ways to closed polygons. MP-Relation,
toBrowseURL());
}
logWayURLs(Level.WARNING, - way:, tempWay);
@@ -810,7 +813,9 @@
*/
private Way singularAreaToWay(Area area, long wayId) {
if (area.isSingular() == false) {
- log.warn(singularAreaToWay called with non singular
area. Multipolygon ,
+ log
+ .warn(
+ singularAreaToWay
called with non singular area. Multipolygon ,
toBrowseURL());
}
if (area.isEmpty()) {
@@ -870,6 +875,9 @@
/**
* This is a QA method. All ways of the given wayList are checked if
they
* they carry the checkRole. If not a warning is logged.
+*
+* @param wayList
+* @param checkRoles
*/
private void checkRoles(ListWay wayList, String checkRole) {
// QA: check that all ways carry the role inner and issue
warnings
@@ -886,37 +894,83 @@
* Creates a matrix which polygon contains which polygon. A polygon
does not
* contain itself.
*
-* @param poplygonList
+* @param polygonList
*a list of polygons
*/
- private void createContainsMatrix(ListJoinedWay poplygonList) {
+ private void createContainsMatrix(ListJoinedWay polygonList) {
containsMatrix = new ArrayListBitSet();
- for (int i = 0; i poplygonList.size(); i++) {
+ for (int i = 0; i polygonList.size(); i++) {
containsMatrix.add(new BitSet());
}
- // mark which ring contains which ring
- for (int i = 0; i poplygonList.size(); i++) {
- JoinedWay tempRing = poplygonList.get(i);
- BitSet bitSet = containsMatrix.get(i);
+ long t1 = System.currentTimeMillis();
+
+ if (log.isDebugEnabled())
+ log.debug(createContainsMatrix listSize:,
polygonList.size());
- for (int j = 0; j poplygonList.size(); j++) {
- boolean contains;
- if (i == j) {
- // this is special: a way does not
contain itself for
- // our usage here
- contains = false;
+ // use this matrix to check which matrix element has been
+ // calculated
+ ArrayListBitSet finishedMatrix = new
ArrayListBitSet(polygonList
+ .size());
+
+ for (int i = 0; i polygonList.size(); i++) {
+ BitSet matrixRow = new BitSet();
+ // a polygon does not contain itself
+ matrixRow.set(i);
+
Re: [mkgmap-dev] Fake warnings in log
Mark Burton escribió: Hello Carlos, Since yesterday the number of similar arcs warnings has increased very much, but when you look at the supposed wrong data, they are correct and there are no recent changes. May be recent commits have introduced some bug in this regard. You can have a look at this one for example: 2010/01/21 09:14:35 ADVERTENCIA (RouteNode): Similar arcs ((N-630 Carretera de Gijón a Sevilla, http://www.openstreetmap.org/browse/way/34954325) and (N-630 Carretera de Gijón a Sevilla, http://www.openstreetmap.org/browse/way/34954325)) from http://www.openstreetmap.org/?mlat=38.32804mlon=-6.32094zoom=17 That warning occurs when you have multiple arcs that have the same start and end points and the same length. It could occur when there are duplicate ways in the map data but also it could occur if the style rules you are using generate multiple routable lines from the same way. I notice that in the above message the OSM ids are the same. That implies that you are generating two roads from one way. It's either a bug in mkgmap or in your style rules. OK, I see. It's due to bridges I have introduced recently in my maps. In some of my attempts to get bridges working I had to add road_class and road_speed to the bridges lines. I suppose removing them will solve the problem, won't it? Thanks for you clarification ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Fake warnings in log
Hi Carlos,
OK, I see. It's due to bridges I have introduced recently in my maps. In
some of my attempts to get bridges working I had to add road_class and
road_speed to the bridges lines. I suppose removing them will solve the
problem, won't it?
Yes, adding class or speed makes a way into a road as far as mkgmap is
concerned.
What I have done for bridges/tunnels is this:
highway=* bridge=yes { delete 'ref'; delete 'name'; } [0x010107 continue
resolution 24]
railway=* bridge=yes { delete 'ref'; delete 'name'; } [0x010107 continue
resolution 24]
highway=* tunnel=yes { delete 'ref'; delete 'name'; } [0x010108 continue
resolution 24]
those types are lines that look like this:
-
-
and the end result looks like this:
--
**
--
The Baltic map has bridges/tunnels like that.
Thanks for you clarification
You're welcome.
Mark
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v2] Major speedup for mp code
Hi WanMil,
On Fri, Jan 22, 2010 at 12:19:31AM +0100, WanMil wrote:
Attached patch can be summarized very easy:
* Major speedup for mp code
Please test and commit if no problems arise.
Sorry for nitpicking, but could you please fix a few formatting issues
and comments in the patch? Some changes look like they could be
accidental, such as this one:
- // mark this ways as artificially closed
+ // mark this ways as artifically closed
way.closeWayArtificial();
The correct spelling is artificially.
@@ -357,8 +359,9 @@
JoinedWay tempWay = it.next();
if (tempWay.isClosed() == false) {
if (first) {
- log.warn(
- Cannot join the following ways
to closed polygons. MP-Relation,
+ log
+ .warn(
+ Cannot
join the following ways to closed polygons. MP-Relation,
toBrowseURL());
}
logWayURLs(Level.WARNING, - way:, tempWay);
@@ -810,7 +813,9 @@
*/
private Way singularAreaToWay(Area area, long wayId) {
if (area.isSingular() == false) {
- log.warn(singularAreaToWay called with non singular
area. Multipolygon ,
+ log
+ .warn(
+ singularAreaToWay
called with non singular area. Multipolygon ,
toBrowseURL());
}
if (area.isEmpty()) {
These apparently are white-space changes that make the code uglier
to my eye. (It is a matter of taste, of course.)
@@ -994,7 +992,7 @@
*
* @param ring1
*a closed way
- * @param ring2 A second closed way.
+ * @param ring2
* @return true if ring1 contains ring2
*/
private boolean contains(JoinedWay ring1, JoinedWay ring2) {
You are removing the parameter description of ring2.
@@ -1079,19 +1135,80 @@
*/
private static class JoinedWay extends Way {
private final ListWay originalWays;
- private boolean closedArtifical;
+ private boolean closedArtifical = false;
+
+ public int minLat;
+ public int maxLat;
+ public int minLon;
+ public int maxLon;
+ private Rectangle bounds = null;
It would be nice to have some comments for all members and
methods of JoinedWay. (OK, it is a work in progress.)
@@ -1180,4 +1298,5 @@
this.ring = ring;
}
}
+
}
It is a matter of taste, but I would not like empty lines between
closing braces.
(I will leave it up to Mark or Steve to commit the patch.
I know too little about the multipolygon code, and I haven't tested
generate-sea after the mp merge.)
Best regards,
Marko
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
