- mkgmap-dev - The mkgmap lists

oneway=reverse handling broken.
by Felix Hartmann 22 Jan '10

22 Jan '10

I noticed that during the last updates oneway=reverse is behaving very very strange. If I have the following rules: highway=* & oneway=reverse & incline=up & mtb:scale:uphill>4 {set oneway=-1} [0x01] highway=* & incline=up & mtb:scale:uphill>4 {set oneway=yes} [0x02] Strangely way is output as 0x02. This has come since the latest additions to the style-file rules. Before it was working very well. Anyone using rules that do set oneway artificially you will have to update your styles. The old way how it worked is now completly broken. I really have problems to understand how "continue" is now interpreted. I personnaly liked the old ("broken") way better, but except for oneway=reverse I think I have been able to adapt (I had to add many many key!=value to stop mkgmap continuing where before it did not continue). The problem is only happening on oneway=reverse only, oneway=-1 is working like it is supposed to do! Maybe oneway=reverse got broken earlier already but I missed it. I just had many many roads being put into the wrong direction since the last changes to the style-mechanism and then tried to accomplish the same result using new rules.

5 20

Commit: r1498: Reduces style rule syntax errors that are caused
by svn commit 22 Jan '10

22 Jan '10

Version 1498 was commited by steve on 2010-01-18 23:02:57 +0000 (Mon, 18 Jan 2010) Reduces style rule syntax errors that are caused by terms being in the wrong order. Terms in the expression are now re-arranged accross the whole of the expression and not just the first two terms. So if there is a term that can be indexed that can be moved to the front without changing the meaning of the expression, then it should now happen.

2 3

R: Use of relations file
by Fabrizio Lorenzini 22 Jan '10

22 Jan '10

I noticed I was using a VERY old (3/2009) version of splitter, now with r104 I am able to get relations in my tiles and to build my map properly! Sorry for the spam, and thank to everyone wich works to mkgmap. Fabrizio

1 0

[PATCH v2] Major speedup for mp code
by WanMil 22 Jan '10

22 Jan '10

Attached patch can be summarized very easy: * Major speedup for mp code Please test and commit if no problems arise. WanMil

3 3

Commit: r1506: When adjusting arc angles, ignore reverse arcs of oneway roads.
by svn commit 22 Jan '10

22 Jan '10

Version 1506 was commited by markb on 2010-01-22 10:01:32 +0000 (Fri, 22 Jan 2010) When adjusting arc angles, ignore reverse arcs of oneway roads. This suppresses the spurious "keep left/right" directions that sometimes occur when a ramp joins a motorway/trunk. For oneway roads that don't allow pedestrian routing, we could probably do without the reverse arcs completely - to be investigated.

1 0

Fake warnings in log
by Carlos Dávila 21 Jan '10

21 Jan '10

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.32804&mlon=-6.32094&zoom=17 Regards, Carlos

3 5

Question on license for style-file
by Felix Hartmann 21 Jan '10

21 Jan '10

I am going to publish my style-file (and dual license the rest like typfiles), but I would like that a) any works that build upon it, have to give attribution to openmtbmap.org b) any maps generated by using the style-file or large parts of it have to give attribution to openmtbmap.org Which license does fit here. Is GnuGPL v2 compatible with my intention or is b) not possible? Would CCBYSA 3.0 be better? Hope someone knows a bit better what I should choose. I don't really understand how b) is treated by open-source licenses.

3 6

R: Use of relations file
by Fabrizio Lorenzini 21 Jan '10

21 Jan '10

>Splitter.jar is not eating my relations, but there could be bugs in it. >Can you please post your areas.list file and the IDs of some eaten relations. >Do the member ways or nodes cross tile boundaries? Hi Marko, here you can find the content of my areas.list file: # List of areas # Generated Thu Jan 14 13:15:21 CET 2010 # 69010001: 1687552,307200 to 2011136,552960 # : 36.210938,6.591797 to 43.154297,11.865234 69010002: 2011136,307200 to 2091008,464896 # : 43.154297,6.591797 to 44.868164,9.975586 69010003: 2011136,464896 to 2091008,552960 # : 43.154297,9.975586 to 44.868164,11.865234 69010004: 1687552,552960 to 1918976,897024 # : 36.210938,11.865234 to 41.176758,19.248047 69010005: 1918976,552960 to 2091008,897024 # : 41.176758,11.865234 to 44.868164,19.248047 69010006: 2091008,307200 to 2195456,413696 # : 44.868164,6.591797 to 47.109375,8.876953 69010007: 2091008,413696 to 2195456,454656 # : 44.868164,8.876953 to 47.109375,9.755859 69010008: 2091008,454656 to 2140160,544768 # : 44.868164,9.755859 to 45.922852,11.689453 69010009: 2140160,454656 to 2195456,544768 # : 45.922852,9.755859 to 47.109375,11.689453 69010010: 2091008,544768 to 2136064,614400 # : 44.868164,11.689453 to 45.834961,13.183594 69010011: 2136064,544768 to 2146304,614400 # : 45.834961,11.689453 to 46.054688,13.183594 69010012: 2146304,544768 to 2195456,614400 # : 46.054688,11.689453 to 47.109375,13.183594 69010013: 2091008,614400 to 2142208,671744 # : 44.868164,13.183594 to 45.966797,14.414063 69010014: 2142208,614400 to 2195456,671744 # : 45.966797,13.183594 to 47.109375,14.414063 69010015: 2091008,671744 to 2195456,897024 # : 44.868164,14.414063 to 47.109375,19.248047 For example one of the missing relations has id 275528, and all her members are in the same tile (690100008). Here is the relation 275528 detail: <relation id='275528' timestamp='2009-11-09T17:27:48Z' uid='80088' user='FedericoCozzi' visible='true' version='7' changeset='3075412'> <member type='way' ref='9659873' role='' /> <member type='way' ref='38115262' role='' /> <member type='way' ref='41863203' role='' /> <member type='way' ref='27328613' role='' /> <member type='way' ref='9659915' role='' /> <member type='way' ref='38114903' role='' /> <member type='way' ref='34567836' role='' /> <member type='way' ref='27447561' role='' /> <member type='way' ref='27447563' role='' /> <member type='way' ref='38210053' role='' /> <member type='way' ref='27446420' role='' /> <member type='way' ref='24748752' role='' /> <member type='way' ref='24748756' role='' /> <member type='way' ref='41863205' role='' /> <member type='way' ref='35540122' role='' /> <member type='way' ref='41863206' role='' /> <member type='way' ref='35540119' role='' /> <member type='way' ref='35540120' role='' /> <member type='way' ref='35540121' role='' /> <member type='way' ref='38117382' role='' /> <member type='way' ref='35540117' role='' /> <member type='way' ref='35540115' role='' /> <member type='way' ref='38211439' role='' /> <member type='way' ref='35540114' role='' /> <member type='way' ref='41863208' role='' /> <member type='way' ref='38210054' role='' /> <member type='way' ref='44060403' role='' /> <tag k='route' v='mtb' /> <tag k='name' v='Rampiledro' /> <tag k='type' v='route' /> <tag k='operator' v='Consorzio Pro Loco Valle di Ledro' /> <tag k='network' v='mtb' /> </relation> Fabrizio

1 0

Commit: r1505: Preserve the end points of horizontal and vertical lines.
by svn commit 20 Jan '10

20 Jan '10

Version 1505 was commited by markb on 2010-01-20 22:15:29 +0000 (Wed, 20 Jan 2010) Preserve the end points of horizontal and vertical lines. This stops the DP filter from discarding the end points of an edge that has been generated by either the clipper or by the polygon splitter. The benefit of this is that it removes some artifacts from polygons that have been clipped or split. It will err on the safe side in that it preserves all edges that are horizontal or vertical but the number of those occurring naturally in the data must be quite small so it should not spoil the filtering effort.

1 0

Commit: r1504: Remove unused FAKE_ID_BASE.
by svn commit 20 Jan '10

20 Jan '10

Version 1504 was commited by markb on 2010-01-20 22:15:25 +0000 (Wed, 20 Jan 2010) Remove unused FAKE_ID_BASE.

1 0