Re: [mkgmap-dev] Is it possible with --add-poi-to-lines option and style rules to create pois only for ways with a min/max/equal length?

[Henning Scholland]

Hi WanMil,
I think it's hard to draw route-icons with line2poi, because the
segments have very different length. There are segments with only a few
meters and also segments with lots of km. For a satisfying rendering you
will need something like route-to-poi, which builds first the complete
route and then adds points in a given distance, eg. 100m or so.

line2poi is more or less only useful for things like adding an icon for
a ford or a entrance of a tunnel.

But I think this isn't that easy to implement and there are actual other
things to do.

Henning

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

Re: [mkgmap-dev] Is it possible with --add-poi-to-lines option and style rules to create pois only for ways with a min/max/equal length?

[Henning Scholland]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Am 27.10.2013 19:12, schrieb WanMil:
 I will have to think about how to realize constant configurable 
 distances between icons. Maybe someone else has a good idea?

Hi WanMil,
did you thought about my approach?

Here again a little bit more detailed:

- - collect all members of a route-relation
- -- if relation-style-file is processed before points, it would be nice
to have a tag like mkgmap:route2poi=true which could set in
relation-file. Only relations with this tag would be processed.

- - connect all connected segments, as a result you will have a number
of ways (similar to gpx-export of cycling.waymarkedtrails.org)

- - for each way take a starting point and insert each length a node
(maybe first search first if there is an existing node in neighbourhood)

A second step could be a similar behaviour as we have for elevation
data (minor, medium, mayor-value).

Option could be: --add-poi-to-routes=100,1000,1

But I don't know, how expensive this would be.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (MingW32)

iQEcBAEBAgAGBQJSbVwXAAoJEPFgsWC7jOeT9kMH/R9MyLpIwAp8cVOp1QmntmO8
7dQnb/6e7412Bb0nvHlGdBiIiriUX+o95O0j+pQm4qucDzNgcvowUTLPnB6qpxgC
Ir86PwJG3oinjWWAV2Fj9Le4fdtFrtSQDkORV+HV0wCmShIt4sTl5/wGo0E8u/AH
Jhhj3J/UWClYj4wiIMD2s64A+ZbNPhpq7+juAEI6hCUZv5C06EyEgx4MSgKKfqeP
p0OUsWa2pANVsG7FE665t16c4Gk/cKniZcAwQQ+u6N5Qge/63fjGzAyLrXgizXVy
s19luIoT0jzS5jwlzFZuEcElzdlgpmxShX8v+VpKiWBD5FjFqXkr+3wnbYepTkg=
=468k
-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] [PATCH v1] finalizer style file

[Henning Scholland]

Hi WanMil,
just to make sure, I've got it right.

way with:
a=b
c=d
e=f

actual in lines:
a=b  c=d {set x=y }
x=y  ef [0x01 ...]

with finalizer:
-in lines:
x=y  e=f [0x01 ..]
- in finalizer:
a=b  c=d  type()=way {set x=y}

If this is true, also the hole addr-part could be moved to finalizer.

Regarding type I think it should better return line, point, relation and
polygon.

Henning

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

Re: [mkgmap-dev] Is it possible with --add-poi-to-lines option and style rules to create pois only for ways with a min/max/equal length?

[Henning Scholland]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Am 29.10.2013 13:50, schrieb Anna Leuchter:
 Hi Henning,
 
 1.
 Option could be: --add-poi-to-routes=100,1000,1
 
 Does this mean that every 100 meters + every 100meters + every
 1 meters of the route a mark would be set? So at 1000m there
 would be 2 marks? One for 100m + one for 1000m? This imo wouldn't
 make sense for waymarks or?

No the intention would be:
Every 100m you will get a node with the tags of the route and a
mkgmap:route2poi=minor. Every 1000m you will get a node with
mkgmap:route2poi=medium and every 1m the tag would be
mkgmap:route2poi=major.


 2. if way is part of multiple routes in this case, like actually
 with the --add-poi-to-lines option, the created marks also might
 created at the same distances/place and than overlaying each
 other. Hardley affected will be only those routes which starts at
 the same point and following partially the same way. Anyway that
 can happens to in the other cases if routes only share some
 intermediate part. In that case the those overlaying marks must be
 shifted a bit, so that all are visisble.

Typical Garmin software shows all POI, if you click next to them. I
don't think that shifting is a good solution, because the distance
depends on zoom level and on the number of routes. This could also
lead to an infinity loop.

Henning

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

iQEcBAEBAgAGBQJSb+h7AAoJEPFgsWC7jOeTWnwIANOHHmrwIwf1hWUuLX8ZNk0R
mW76Y9OtcO9sdKzWF0KEOXIT70tQkDda3IbNNdnIlGmqAWtR6jb0YnJ13rtuE8Zx
/K2FH83jwHfgocwrmMEpUjL0tEZOPWMEVFq9T6Bc3WD0mOROPYnFcAzOaFj6muV8
MHh6BHCSnpwmhgF5ejkXjAiwRvHeQwNuFUw36LusmepnTnbn3s0T9GkF0mrwliB+
bn7wtifDhMRliG79IdLG7L+2vPpcQXuhbwxDPjlqlyUzkkVk/AQgCS8k2hoN6utl
85+Yis7YvFaeSWfQYdUIs/58MsG2HD2wMqgp3ZO6LfFUH4FLgyyFqdIvSloxdBY=
=lRCZ
-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

[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

[Henning Scholland]

Am 03.11.2013 13:23, schrieb Steve Ratcliffe:
 
 We could use a different notation such as get_tag(maxspeed) since it
 would be clearer that it could not be quoted.

Hi Steve,
I would prefer something like get_value(..) or value_of(..) or simply
value(..)

tag is in OSM a word for key=value, so get_tag doesn't make sense,
because you'll just get the value from a given key.

Henning

___
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

[Henning Scholland]

Am 03.11.2013 12:56, schrieb Steve Ratcliffe:
 The second means that you can write just
 
   minspeed  $maxspeed
 
 and it will be converted automatically to:
 
   minspeed=*  minspeed  $maxspeed

Wouldn't it be more logical to convert it to:

minspeed=*  maxspeed=*  minspeed  $maxspeed

Henning

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

Re: [mkgmap-dev] Multiple relations

[Henning Scholland]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Am 06.11.2013 11:48, schrieb demon.box:
 How can you see the image attached MapSource display tha name of
 the highway (not the name of the route relation) if there is one or
 the label Sconosciuto if there isn't. I would delete (I don't
 want to see it). It is possibile?

Hi enrico,

I think this name comes from your TYP-file. There you can set a
default name, which is displayed if there is no name given to the
garmin-object.

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

iQEcBAEBAgAGBQJSfesXAAoJEPFgsWC7jOeT44AIAMVFtXRQ7p6gzadm6mLmTYMh
rh9eYVcw07bV0pdYE82ek/yKqZguVMlZggplZIecGarDgMonP5oxeX1PskaL0SEp
4C3fJNAM5HYMo04rla72v3Dqq5l6ymObK+nT6qkdYYk5h7K2+OjtCm15AWT3MKPA
5OWtUzaHcXJ/EpkT3If7TM7Jlj/W7dKfIrLZ3uummmnUg/ZNMQHVKvRU06UBi+E4
kfts7FEm2k3jJLcv5jRhlZy9HK6TVfLBHGkHJgoASxup25JheXhZmvcC5uY2YWZT
YvG5Wc9efMQIBiH6jw2kqHWpiWgY1QSXVNBqOFeEnTx8EUIPMLasphx09a+5thc=
=r4ju
-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] Drive-on-left

[Henning Scholland]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Yes, but it should be unique in each country. So it should be possible
to use a mkgmap:drive_on=left or something similar.

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

iQEcBAEBAgAGBQJShjTpAAoJEPFgsWC7jOeTxdUIAOKwTZz3AIHGTnAvxw3p+xoB
8uNZ66gdz2dcCggyca+Gvba/8/SLQQNgofn4O9PnCszwRTLer1SXKcIragTcr8ji
rZTyiyhb6T1zDR0OoVbri8gvXDvdSoriS9ADWPMj0riDFyeENT5oG6UXekwXJneT
SSb4FnK0no959WD8+kXVjIQqy/+ivAW5oKmLdvnMCZyStjFNNGyS5nIMNdVED+lE
0zZWojL4pTVYVNKjMzzuBBbs78oL9Byv5nUIGDaVf331AT/RQyIHYNkwbFFIsg+A
CNAy0qhMeXPKjaSYdu/6ak1kl0S7zBvLfUyIDmIbU8oA8aE0/23uuH+Zq3q8sRA=
=e2qK
-END PGP SIGNATURE-

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

Re: [mkgmap-dev] o5m plugin for JOSM

[Henning Scholland]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Gerd, maybe you should create a ticket for that in the bug-tracker:

http://josm.openstreetmap.de/newticket

btw: I'm waiting for a very long time for such a plugin :-) Thanks a lot!

Henning

Am 22.11.2013 09:31, schrieb Gerd Petermann:
 Hi all,
 
 in february I wrote a plugin for JOSM to allow importing o5m files
 (which helps me debugging). I posted that via in the JOSM group
 josm-...@openstreetmap.org, but I did not notice that my post did
 never reach that list. See 
 http://gis.19327.n5.nabble.com/Patch-v1-o5m-support-for-JOSM-tp5749699.html

  The plugin worked fine for me without any changes, so if anybody
 interested in this I'll try to subscribe to the JOSM list.
 
 Gerd
 
 
 
 
 
 
 ___ mkgmap-dev mailing
 list mkgmap-dev@lists.mkgmap.org.uk 
 http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)

iQEcBAEBAgAGBQJSj3nfAAoJEPFgsWC7jOeT7XQIAIESmvhAL8LGaDgldL7PqQMe
SU6WCRqmgpyssmm9jKBAdEZ/F8qAawPvC20+OIhLTdODZ7Wme52Qwlm41r6ugywx
eAkbjjyfAEIw3Y8SDdWLTKdUqsS/agzIGmTTdht/xzXp+3z05nrHWENeU5gJk87+
YYzER1o1pbu2MsNLW5bI23zvFAHy/wQDbvPMRYTw/EO+E/bM/BjhKOMY+0m8gf8s
BJWrT4nz93HGZIfVOwegjoa5HxVnReRZdBnPmRUzdjMvAQkw26xILIocJQDBxgOf
J2+NZC5zGl4SDF5EjROcc7OE9Agg555BwPzr2zGMFPNnmDLfC2sEgv4jDa4pdZA=
=05Mx
-END PGP SIGNATURE-

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

[mkgmap-dev] IO-problem with actual trunk

[Henning Scholland]

Hi,

while generating a map of Oman I got the attached error-message (see
below 1010). The map is generated out of planet.o5m.

Henning

1000
1001
SEVERE (Main): 1001*.o5m: file 1001*.o5m doesn't exist
Exiting - if you want to carry on regardless, use the --keep-going option
1002
1003
1004
1005
1006
TYP file cannot be written in code page 1251
1008
SEVERE (MapSplitter): 10080054.o5m: Area too small to split at http://www.openstreetmap.org/?mlat=-43.27251mlon=170.86459zoom=17 (reduce the density of points, length of lines, etc.)
1009
1010
java.io.IOException: Das Argument ist ungültig
	at java.io.FileInputStream.skip(Native Method)
	at java.io.BufferedInputStream.skip(BufferedInputStream.java:366)
	at uk.me.parabola.mkgmap.reader.osm.o5m.O5mBinHandler.skip(O5mBinHandler.java:178)
	at uk.me.parabola.mkgmap.reader.osm.o5m.O5mBinHandler.readFile(O5mBinHandler.java:158)
	at uk.me.parabola.mkgmap.reader.osm.o5m.O5mBinHandler.parse(O5mBinHandler.java:106)
	at uk.me.parabola.mkgmap.reader.osm.o5m.O5mBinMapDataSource.load(O5mBinMapDataSource.java:45)
	at uk.me.parabola.mkgmap.reader.osm.OsmMapDataSource.load(OsmMapDataSource.java:127)
	at uk.me.parabola.mkgmap.main.MapMaker.loadFromFile(MapMaker.java:167)
	at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:63)
	at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:220)
	at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:216)
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
	at java.util.concurrent.FutureTask.run(FutureTask.java:166)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
	at java.lang.Thread.run(Thread.java:724)
java.lang.ArrayIndexOutOfBoundsException: -131421472
	at uk.me.parabola.mkgmap.reader.osm.o5m.O5mBinHandler.setStringRefPair(O5mBinHandler.java:345)
	at uk.me.parabola.mkgmap.reader.osm.o5m.O5mBinHandler.readAuthor(O5mBinHandler.java:398)
	at uk.me.parabola.mkgmap.reader.osm.o5m.O5mBinHandler.readVersionTsAuthor(O5mBinHandler.java:362)
	at uk.me.parabola.mkgmap.reader.osm.o5m.O5mBinHandler.readWay(O5mBinHandler.java:235)
	at uk.me.parabola.mkgmap.reader.osm.o5m.O5mBinHandler.readFile(O5mBinHandler.java:150)
	at uk.me.parabola.mkgmap.reader.osm.o5m.O5mBinHandler.parse(O5mBinHandler.java:106)
	at uk.me.parabola.mkgmap.reader.osm.o5m.O5mBinMapDataSource.load(O5mBinMapDataSource.java:45)
	at uk.me.parabola.mkgmap.reader.osm.OsmMapDataSource.load(OsmMapDataSource.java:127)
	at uk.me.parabola.mkgmap.main.MapMaker.loadFromFile(MapMaker.java:167)
	at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:63)
	at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:220)
	at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:216)
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
	at java.util.concurrent.FutureTask.run(FutureTask.java:166)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
	at java.lang.Thread.run(Thread.java:724)
Exiting - if you want to carry on regardless, use the --keep-going option
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] IO-problem with actual trunk

[Henning Scholland]

Here it is: http://www.aighes.de/data/1010.tar.gz

Henning



Am 22.11.2013 19:28, schrieb GerdP:
 Hi Henning,
 please post a link to the o5m input file.
 
 Gerd
 
 
 Henning Scholland wrote
 Hi,

 while generating a map of Oman I got the attached error-message (see
 below 1010). The map is generated out of planet.o5m.

 Henning

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

 mkgmap_error.log (3K)
 lt;http://gis.19327.n5.nabble.com/attachment/5786885/0/mkgmap_error.loggt;
 
 
 
 
 
 --
 View this message in context: 
 http://gis.19327.n5.nabble.com/IO-problem-with-actual-trunk-tp5786885p5786888.html
 Sent from the Mkgmap Development mailing list archive at Nabble.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

Re: [mkgmap-dev] IO-problem with actual trunk

[Henning Scholland]

Am 23.11.2013 09:36, schrieb Gerd Petermann:
 Hi Henning,
 
 okay, maybe it was an error in the update process. I see that
 e.g. OSM stats also had problems:
 http://osmstats.altogetherlost.com/index.php?item=nodes
 
 Anyway, it is obvious the code in splitter is missing a check,
 either in the o5m read or in the write routine (or both) :-(
 
 If you can reproduce the problem with the downloaded planet,
 maybe try to use --output=pbf first.
 
 Gerd

Hi Gerd,
I'm not that familiar with o5m-format, but it is possible,, that only a
part of the world is corrupted?
Maybe you remember, that I'm splitting all my maps at ones. And all
other maps are correct. If it's not possible, I think splitter have a
problem with this.

Also I can update the used planet-file with osmupdate.

Henning

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

Re: [mkgmap-dev] Possible solution for deformed polygons

[Henning Scholland]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Gerd,
if this merging is done after style-processing, then it should be a
great improvement without complications. Otherwise only polygons
should be merged if all tags are equal.

Henning

Am 23.11.2013 16:25, schrieb GerdP:
 Hi Andrzej,
 
 for address search the data is saved with the roads, not with the
 polygons and poi are separate points, so I don't see a problem
 here. I did not yet start coding, as I still try to find a better
 algo for the bad angles in roads.
 
 Gerd
 
 
 popej wrote
 Hi Gerd,
 
 1) merge polygons with equal types etc. like in merge-lines
 algo, so that e.g. buildings that share walls are combined to
 one polygon  (without creating holes).
 
 I would expect that many buildings have address tag which would
 make merging not advisable.
 
 How merging would cooperate with option add-pois-to-areas?
 
 -- Best regards, Andrzej 
 ___ mkgmap-dev
 mailing list
 
 mkgmap-dev@.org
 
 http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
 
 
 
 
 
 -- View this message in context:
 http://gis.19327.n5.nabble.com/Possible-solution-for-deformed-polygons-tp5786064p5786952.html

 
Sent from the Mkgmap Development mailing list archive at Nabble.com.
 ___ mkgmap-dev mailing
 list mkgmap-dev@lists.mkgmap.org.uk 
 http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)

iQEcBAEBAgAGBQJSkNa2AAoJEPFgsWC7jOeTG+EIALR1DG4mMeJ1996r8ZMJJJxX
qb8r0vN5E67Iai4bURr4za2G2BGCVaukvdvjEA78V3SwTakcDGXOc/Y+oCiXgp6j
dcWLE/tdeP9bsd8dM8WI9jOsoIvXZOzpun5q8H+HbWZbj5xZOVGJooDMJCNb5Gi7
L42NyLOobR1eVUztwdl4AoVrXok69UI18I5+gQKv0RacOcVvPWGPEjzxclHHDiqH
1wmJruf26VaEtXpZGGpAN0Shbzx3Vex/G8B+EX8dqOI7iN83SqBLQMBL0zXu5QWs
WxBJrZX3He5uw6AlliA9sg3p8mxAfK2XElp09Rd7ZgfqNApNQmp7WfTWFwWhUjY=
=TfIG
-END PGP SIGNATURE-

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

Re: [mkgmap-dev] IO-problem with actual trunk

[Henning Scholland]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Gerd,
works as expected.

Henning

Am 23.11.2013 15:11, schrieb Gerd Petermann:
 Hi Henning,
 
 I was not able to reproduce the problem, but I found a potential 
 error in the o5m write routine: it did not write enough reset
 bytes. I've changed that in r313. Please try if this helps.
 
 Gerd
 
 Date: Sat, 23 Nov 2013 10:26:07 +0100 From: o...@aighes.de To:
 mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev]
 IO-problem with actual trunk
 
 Am 23.11.2013 09:36, schrieb Gerd Petermann:
 Hi Henning,
 
 okay, maybe it was an error in the update process. I see that 
 e.g. OSM stats also had problems: 
 http://osmstats.altogetherlost.com/index.php?item=nodes
 
 Anyway, it is obvious the code in splitter is missing a check, 
 either in the o5m read or in the write routine (or both) :-(
 
 If you can reproduce the problem with the downloaded planet, 
 maybe try to use --output=pbf first.
 
 Gerd
 
 Hi Gerd, I'm not that familiar with o5m-format, but it is
 possible,, that only a part of the world is corrupted? Maybe you
 remember, that I'm splitting all my maps at ones. And all other
 maps are correct. If it's not possible, I think splitter have a 
 problem with this.
 
 Also I can update the used planet-file with osmupdate.
 
 Henning
 
 ___ 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
 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)

iQEcBAEBAgAGBQJSkSbBAAoJEPFgsWC7jOeTYnYH/Rjsy/qYyTw54lXzEarFdpj0
EBOxV53ug008pO6Bn1lv2NFochKU8WV4IVpYIxTWfQVTxc/XNvkuR1O45RpcoNki
lnrvdeyKuCFyyfLqqeu5kzZ9Ed9YYufWf0IpaAnXGjvPYv0x2WAY5oLRa2A4q9Sx
jVDhkQaYurBnCnTAjotYtVT7aqppi0CBRi5ZFLbHkhs/stXW5zemh5QekSZqub6a
sCPUiyoixH7snTaWezQJQ5v19CBgEHlGa1Cl/KVyhNXob4LWhf9pqEoUXtIyrwL6
hP0S1rx+Ne5kkeBn2tG8no1bjZWK/nWVi3tiVZNnDwR6P25797uprkSoVvQCJFg=
=0f7Q
-END PGP SIGNATURE-

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

Re: [mkgmap-dev] TYP-file can't be written

[Henning Scholland]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Steve,

in the end of August it worked without any problems. I've just read
here that something was changed with TYP-files and code-page.

My TYP-file you'll find here:
https://github.com/aighes/RadReiseKarte/blob/master/resources/rrk_typ.txt

It's containing ö,ü,ä and ß.

Henning

Am 24.11.2013 15:01, schrieb Steve Ratcliffe:
 On 23/11/13 22:12, Henning Scholland wrote:
 In the header of my txt-TYP-source I have written CP1252.
 Converting this to CP1250 and CP1254 is done without problems. So
 I don't understand, why it's a problem for CP1251 and CP1256. Any
 guesses?
 
 I will need a few more details if you think there is a bug and you 
 think that the labels could be written in CP1251 and 56.
 
 But in general there is no transliteration, so the characters you
 use must be in the target character set.
 
 cp1250 and cp1254 share many of the common characters from cp1252
 that you are likely to be using and so might work, whereas 1251 and
 1256 are very different and may not contain the characters you are
 using.
 
 ..Steve
 
 ___ mkgmap-dev mailing
 list mkgmap-dev@lists.mkgmap.org.uk 
 http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)

iQEcBAEBAgAGBQJSkg7qAAoJEPFgsWC7jOeTCDoH/RY05Dukbx2/JCLCPpg57Zph
wReqNpeJPTnd5doboxmIOa6NJGtlS7AkMKA/2pmM6Rl5CbFcYQQQ9ZEl3eZ5uWLh
pKm33R3yGZE6xGvbX3BKnPQ1Map2o79chzwNj6pgu8a/admXtm/z1umyuRJu5jvz
C7V5606ffLOxp0/OH37eZYdUoUVgeT2iry8Vmm9E3Skr+hNTi08QZPRA6t3w++fz
U/W9NWc9EEU7foWiCoyWZtI5wprUI6CYbnXk699SEjzMhUvyyxPtxjfC2E9pmFZd
36L99tLUPEdOo8TyEFQt9Xe8yNMnzyUyqmbWetUQDihYLvMF0oy0XyOS7ACx3iw=
=yB0C
-END PGP SIGNATURE-

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

Re: [mkgmap-dev] IO-problem with actual trunk

[Henning Scholland]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Gerd
Here it is: http://www.aighes.de/data/mkgmap.zip

Henning

Am 24.11.2013 09:02, schrieb Gerd Petermann:
 Hi Henning,
 
 I still don't understand why this change is important for mkgmap,
 maybe I did not fix the real problem. It would be great if you
 could reproduce it again with r312 and --output=o5m . The problem
 was e.g. in file 10100011.o5m. Next, execute splitter r312(or r311)
 with --output=pbf and post a link to both files.
 
 Gerd
 
 Date: Sat, 23 Nov 2013 23:05:54 +0100 From: o...@aighes.de To:
 mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev]
 IO-problem with actual trunk
 
 Hi Gerd, works as expected.
 
 Henning
 
 Am 23.11.2013 15:11, schrieb Gerd Petermann:
 Hi Henning,
 
 I was not able to reproduce the problem, but I found a
 potential error in the o5m write routine: it did not write
 enough reset bytes. I've changed that in r313. Please try if
 this helps.
 
 Gerd
 
 Date: Sat, 23 Nov 2013 10:26:07 +0100 From: o...@aighes.de
 To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re:
 [mkgmap-dev] IO-problem with actual trunk
 
 Am 23.11.2013 09:36, schrieb Gerd Petermann:
 Hi Henning,
 
 okay, maybe it was an error in the update process. I see
 that e.g. OSM stats also had problems: 
 http://osmstats.altogetherlost.com/index.php?item=nodes
 
 Anyway, it is obvious the code in splitter is missing a
 check, either in the o5m read or in the write routine (or
 both) :-(
 
 If you can reproduce the problem with the downloaded
 planet, maybe try to use --output=pbf first.
 
 Gerd
 
 Hi Gerd, I'm not that familiar with o5m-format, but it is 
 possible,, that only a part of the world is corrupted?
 Maybe you remember, that I'm splitting all my maps at ones.
 And all other maps are correct. If it's not possible, I
 think splitter have a problem with this.
 
 Also I can update the used planet-file with osmupdate.
 
 Henning
 
 ___ 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
 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)

iQEcBAEBAgAGBQJSkisgAAoJEPFgsWC7jOeT90UH/i8z82v8ysHXuw8iOK4+OrWk
FMMz7lWY/E6ngsijFUijWxflA8NZDkavwuc08QSyg+7x6y+cSa53u31hQYTzIYhc
FZGz47NRSWc/pkSC9I2BNu6uFdRDjOQgPP/1HKVzHfcwXvTNn4C4cr1CXdOMGOD3
pKOjhSP9N1y1htGGCyg5ujTcLmQjRlbjzbL3cvg0TYqDYjYucnzxTUzRCopMn3cL
f6Ew/QcBIc/wF3pHkl9oEaKoLb60AXl/4o1apJrZF12mxNFpM/ffyI8nTn8AAJZc
fHs91VS4QrQkWppX1OidPhVpRj9HbGUNke2Ne+qBL+Jxs6CIDWy9EadfsLz0qlE=
=kkbL
-END PGP SIGNATURE-

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

Re: [mkgmap-dev] TYP-file can't be written

[Henning Scholland]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Steve,

I don't want to bother you. Is there any news about this?

Henning

Am 25.11.2013 00:17, schrieb Steve Ratcliffe:
 Hi Henning
 
 in the end of August it worked without any problems. I've just
 read here that something was changed with TYP-files and
 code-page.
 
 The change was that the --code-page parameter overrides the 
 CodePage that is in the typ txt file. That may well have been a
 bad idea. It certainly is in this case.
 
 Previously you would have had a cp1252 TYP file with the tiles
 being in a different code page (unless you changed the CodePage in
 the typ txt file too).
 
 You should be able to work around the problem by using
 --code-page=1252 just before the .txt file and then setting it back
 to what it should be just after.
 
 I am tempted to revert that part of the change, but will have to 
 look at why I made it in the first place.
 
 ..Steve ___ mkgmap-dev
 mailing list mkgmap-dev@lists.mkgmap.org.uk 
 http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
 

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

iQEcBAEBAgAGBQJSsJ2XAAoJEPFgsWC7jOeTg3QIAJWqJCMiGWA86DokRgGBnyWb
SIexcvljpJkBitRpZ3uMauijs9vOUOvLIBZanB6dofSh0ef8kU9LUkrkBWx0ctqg
zd/534wZq7w3piKBp8m+1MBlp5zRWoOdZArnov8dleShn2ol5Gj9bOdm0rA45Pn+
At5vQOevMpdW3VvXYjw1wmFpBbrgwaYvS3P6DvY/7osJkNjPp9IqQbU9rY3qlqB2
Cmv0oc+i0Juzki+j/L198UZNEd83SaYbHcydeB4fpvqZU4uqhgZbjjb8C7IH0skC
nu8YwEeSmQ20no+b4Nu0Pse5u3eLM8J+gIKiFLAtPOidNh11UxLw2hYIzQYlrBY=
=eEK3
-END PGP SIGNATURE-

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

Re: [mkgmap-dev] Address search confused by place=* with name,ref

[Henning Scholland]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Marko,
for me it sounds like a bug in OSM, which should be fixed.

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

iQEcBAEBAgAGBQJSuUlfAAoJEPFgsWC7jOeTijoIAMrkT79PM51nJyrieyykpFNg
xqOsWeb7UEbcgP4+IK6aX1RL1ncxFITtIaMlnbxJCevCYMFe/3jV4Ryyy9ZjyPNe
QyVe46lWT3oEu3XqzlQm+wwTXTbZZ2NCLaXkNZbQUGaGPcXnuR1RNHnG7k4eGb2w
6ERj11G8POux3oh0coLNqnCgpLVZlEiRBRVRVvi/BlkUPHZ4aqz854bVHmwvxvmb
/09QPb7xBNJEE+tgREGtuuIn+GJknhzP2nIobBphd+ZGqfLxYFbp3XZMyH48h76/
GJUgIxj/un6p2gS8cFxXO5O1Tb727VxfkTQWwf+Wi5MR5lSyxHhR5bG3w5BEVow=
=Q6Xr
-END PGP SIGNATURE-

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

Re: [mkgmap-dev] [patch v1] link-pois-to-ways and restrictions

[Henning Scholland]

Am 24.12.2013 09:40, schrieb chris66:
 Am 23.12.2013 15:15, schrieb Gerd Petermann:
 
 What do you mean with route restrictions ?
 
 sorry, a route restriction is the internal name for it.
 These route restriction are created for restriction relations
 like http://wiki.openstreetmap.org/wiki/Relation:restriction
 
 Ah ok so you mean turn-restrictions. What is the advantage for
 implementing the point-barriers this way?

Hi Chris

Think about a POI you want to route to. The road passing this POI has a
barrier in front of the POI and with old implementation the passing road
will be avoided for eg. 100m Maybe there is another road passing the
other POI-side (without entrance), which passes the POI in 80m. So
Garmin will route you to a point of the useless side of the POI, just
because it's closer.
With new implementation you will be routed to the passing road and
routing will stop at the barrier.

Henning

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

Re: [mkgmap-dev] Address search confused by place=* with name,ref

[Henning Scholland]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Marko,

if you find something like Xi:xii Kyttälä, FIN in a name-tag, then
this shoulod be wrong for a town. The name of the town would be
Kyttälä, or am I wrong?

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

iQEcBAEBAgAGBQJSuhNXAAoJEPFgsWC7jOeTUQkH/178+7v+PHBIUK/gV/MrN8XE
mobefCBQqc+LxLaq66orEUqxJm05+REZlHQ7xD8qUi/YrjjblGofg6gwH8/xrorj
m6/xvqTA7cnMKCXweV0VKyM6P4UC8VJGbp7eZCNVJXrnoFot4Q7ElQYrqC327lUH
QP+TIl72+OW8BizP3h6Tmw/o28htduyqM6FCupITuWChzbFSOBdqhy4tkXMsBR06
TQQIT/JV3cDzp8hucOBeP3/weR0ba1/Opz/sr2rXc3bsmIipXlE1LdFsw7WvbP9O
HlYSAnVnEBGfG0aouRFGyPZeBT4aLy7h2UQDaP19bD+YXXaMQASs+yXnUiqaY68=
=Owuy
-END PGP SIGNATURE-

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

Re: [mkgmap-dev] Address search confused by place=* with name,ref

[Henning Scholland]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Marko,

ok so I misunderstood you. You wrote something of filtering osm.pbf
with osmosis and afterwards there were elemets with name Xi:xii
Kyttälä, FIN. But as you explained now, mkgmap creates this name. So
I agree with you: Your given name shouldn't be generated by mkgmap.

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

iQEcBAEBAgAGBQJSusJBAAoJEPFgsWC7jOeTpMsH/0hMujyRuYMbjiUa6KEIfd6t
b1jUeYW+Bqocuc5tJ3GhD14kHY9UbuGVIl4oqW690jGMmaArg14WJve/tuClDWFI
nt1DxZkFIv7PsRhWb8w3RVwiTkjzhmL11gKOqUjzqk+8kYdcHI53Jyf1XAsE2Qt6
qatPaNb0LosyxM7okMntHIeeiBTTkHV2xekupWaatLkzaVGHN6jLNlFW26fWDec6
FUIikTZ7g8Z6SlQZfYZAQIt562k8F8X/DZ6G7P71pYIe4bx1mF4P3gTyqj9AwdD9
b9paGnFkt1Ftc/w1+thd8LyixqAwtuRCgAyoCyqyE1qYoX7F5QpvM+ELL8Ej3ZI=
=TCeO
-END PGP SIGNATURE-

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

Re: [mkgmap-dev] coastline boundaries

[Henning Scholland]

Hi Gerd,
I don't know what you discussed with WanMil, but I think it would be 
better to use mkgmap:coastline=yes in combination with precompiled sea 
polygons and keep the original way completly untouched (as you did 
already). In this case no special handling for natural=coastline is 
necessary. Such a special handling isn't easy to understand.


While processing mkgmap has to decide, if precompliled data should be 
used or original data. If precompiled data is used, mkgmap is using 
mkgmap:coastline=yes for generation, otherwise natural=coastline is used.


Henning

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

Re: [mkgmap-dev] coastline boundaries

[Henning Scholland]

Hi Gerd,

processing the precompiled data through style isn't necessary. But I 
would leave it to the style-dev to take care about rendering 
natural=coastline also in polygon-file or not. After thinking some 
minutes more, my approach isn't that better then yours, if you remove 
the ignore function for polygon-file.


Henning

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

Re: [mkgmap-dev] Distorted lines

[Henning Scholland]

Am 19.02.2014 10:26, schrieb Gerd Petermann:

Are you also satisfied with the results?


Absolutly! Looks smoother and maps are smaller, win-win-situation.

Thanks a lot,
Henning

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

[mkgmap-dev] Splitter and multiple input-files

[Henning Scholland]

Hi Gerd,
I discovered a (small) problem with using two inputfiles with splitter. 
One input-file is planet.osm, the other one is a srtm-files covering 
only a few areas. If I split an area, which is not covered by the bbox 
of my srtm-file, splitter wont write any areas.list and so on. Would it 
be possible to merge the bboxes of the input-files or check, that the 
required area is coverd at least by one input and not necessarily by all?


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

Re: [mkgmap-dev] Splitter and multiple input-files

[Henning Scholland]

Hi Gerd,
yes you got it right, as you mean touch as touched by bbox of 
srtm-file. The srtm-file contains Iceland (NW) and New Zealand (SE). 
Every poly-file works, which touch this area. Now I tried to split a 
part of Canada and it failed.


To sumerize the log: It split planet as normal and after this splitter 
tries to start the same with srtm-file and returns something like poly 
does not touch input-file, please use a polygon, ...


If you need the log, I will generate one.

Henning


Am 03.03.2014 19:47, schrieb Gerd Petermann:

Hi Henning,

just to make sure that I got it right.
You have planet and the srtm-data as input and a polygon-file that 
doesn't touch the area covered by the srtm data.

Can you send the splitter.log so that I can see what it does?

Gerd


Date: Sun, 2 Mar 2014 22:47:44 +0100
From: o...@aighes.de
To: mkgmap-dev@lists.mkgmap.org.uk
Subject: [mkgmap-dev] Splitter and multiple input-files

Hi Gerd,
I discovered a (small) problem with using two inputfiles with 
splitter. One input-file is planet.osm, the other one is a srtm-files 
covering only a few areas. If I split an area, which is not covered by 
the bbox of my srtm-file, splitter wont write any areas.list and so 
on. Would it be possible to merge the bboxes of the input-files or 
check, that the required area is coverd at least by one input and not 
necessarily by all?


Henning

___ 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] high-prec-branch ready for trunk?

[Henning Scholland]

Me too.

Henning

Am 04.03.2014 09:07, schrieb Thorsten Kukuk:

On Tue, Mar 04, Gerd Petermann wrote:


If I hear no complains I'll merge on March 6.

Fine with me, I'm using that branch already for my maps and haven't
heard anything negative back yet.

   Thorsten



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

Re: [mkgmap-dev] Splitter and multiple input-files

[Henning Scholland]

Hi Gerd,
attached you'll find my splitter-log, the skript and the poly-file.
Maybe this helps.

Henning

Am 04.03.2014 08:16, schrieb Gerd Petermann:
 Hi Henning,
 
 I can't reproduce it with r317. I've tried it like this: Use (an
 older) planet.o5m and an srtm file covering Bremen and Bremerhafen
 (got it from you)
 
 My options --write-kml=splitter.kml --output=o5m --max-areas=2048
 --polygon-file=f:\osm\canada.poly  f:\osm\planet.o5m
 f:\temp\henning\srtmtest.osm Both input files contain boundaries
 and splitter works as it should.
 
 Maybe you use a different order of options?
 
 Gerd
 
 
 
 Date: Mon, 3 Mar 2014 20:23:23 +0100 From: o...@aighes.de To:
 mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Splitter
 and multiple input-files
 
 
 
 
 
 
 Hi Gerd,
 
 yes you got it right, as you mean touch as touched by bbox of 
 srtm-file. The srtm-file contains Iceland (NW) and New Zealand 
 (SE). Every poly-file works, which touch this area. Now I tried to 
 split a part of Canada and it failed.
 
 
 
 To sumerize the log: It split planet as normal and after this 
 splitter tries to start the same with srtm-file and returns 
 something like poly does not touch input-file, please use a 
 polygon, ...
 
 
 
 If you need the log, I will generate one.
 
 
 
 Henning
 
 
 
 
 
 Am 03.03.2014 19:47, schrieb Gerd Petermann:
 
 
 
 
 Hi Henning,
 
 
 
 just to make sure that I got it right.
 
 You have planet and the srtm-data as input and a polygon-file that
 doesn't touch the area covered by the srtm data.
 
 Can you send the splitter.log so that I can see what it does?
 
 
 
 Gerd
 
 
 
 
 Date: Sun, 2 Mar 2014 22:47:44 +0100
 
 From: o...@aighes.de
 
 To: mkgmap-dev@lists.mkgmap.org.uk
 
 Subject: [mkgmap-dev] Splitter and multiple input-files
 
 
 
 Hi Gerd,
 
 I discovered a (small) problem with using two inputfiles with
 splitter. One input-file is planet.osm, the other one is a
 srtm-files covering only a few areas. If I split an area, which is
 not covered by the bbox of my srtm-file, splitter wont write any
 areas.list and so on. Would it be possible to merge the bboxes of
 the input-files or check, that the required area is coverd at least
 by one input and not necessarily by all?
 
 
 
 Henning
 
 
 
 ___ 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
 
warning: --keep-complete is only used for the first input file.
Bounding polygon doesn't intersect with the bounding box of the input file(s)
Failed to calculate areas. See log for details.
-threads=6
mixed=false
no-trim=false
output=pbf
output-dir=
overlap=auto
polygon-file=./resources/poly/Canada-SW.poly
precomp-sea=
problem-file=
problem-report=
resolution=13
split-file=
status-freq=0
stop-after=split
write-kml=./resources/kml/Canada-SW.kml
Time started: Tue Mar 04 22:25:49 CET 2014
Map is being split for resolution 13:
 - area boundaries are aligned to 0x800 map units (0.0439453125 degrees)
 - areas are multiples of 0x800 map units wide and high
Processing ./data/planet.o5m
10.000.000 nodes processed... id=35044812
20.000.000 nodes processed... id=47365376
30.000.000 nodes processed... id=58892408
40.000.000 nodes processed... id=70704263
50.000.000 nodes processed... id=82698776
60.000.000 nodes processed... id=94038587
70.000.000 nodes processed... id=106531719
80.000.000 nodes processed... id=118376341
90.000.000 nodes processed... id=129219757
100.000.000 nodes processed... id=142382389
110.000.000 nodes processed... id=153801513
120.000.000 nodes processed... id=165067518
130.000.000 nodes processed... id=176075231
140.000.000 nodes processed... id=187197222
150.000.000 nodes processed... id=197991560
160.000.000 nodes processed... id=208985911
170.000.000 nodes processed... id=219742060
180.000.000 nodes processed... id=230810513
190.000.000 nodes processed... id=244221235
200.000.000 nodes processed... id=258460377
210.000.000 nodes processed... id=273149915
220.000.000 nodes processed... id=287968785
230.000.000 nodes processed... id=303316532
240.000.000 nodes processed... id=317582479
250.000.000 nodes processed... id=330878021
260.000.000 nodes processed... id=346410478
270.000.000 nodes processed... id=363307382
280.000.000 nodes processed... id=377473108
290.000.000 nodes processed... id=393876411
300.000.000 nodes processed... id=406749580
310.000.000 nodes processed... id=421844289
320.000.000 nodes processed... 

Re: [mkgmap-dev] splitter and srtm2osm

[Henning Scholland]

Hi Michal,

I would recommend to use phyhgtmap instead of srtm2osm. You'll get 
splitted ways (number of nodes can be specified) and it writes 
pbf-files, which is more effective.


Henning

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

Re: [mkgmap-dev] Infinite loop splitter

[Henning Scholland]

Hi Minko,
is there a reason for merging the files before splitting? Did you try to 
just pass all the files to splitter? I'm doing so with osm and 
srtm-data. Don't know, if this helps in this case, but in general I 
think it should be much faster.


Henning

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

Re: [mkgmap-dev] options make-all-cycleways and make-cycleways

[Henning Scholland]

As I remember correct, the result was: You should use continue or
continue_with_actions instead of these cycleway-options. ;)

Henning

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

Re: [mkgmap-dev] conditional includes in style

[Henning Scholland]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Gerd,
I quote a mail, which I wrote some month ago to the list:

 
 while cycling in New Zealand I found out, thats a little bit to
 easy just taking a style (routing and map-look) and use it in parts
 of the world, which are very different to Central Europe. Eg. it's
 not that interesting if the road is a trunk or a unclassified, but
 it's very interesting to show if a road is sealed or unsealed.
 
 If there are only small things, which are country-specific it's
 pretty easy to use just  mkgmap:country=???. But this will makes
 the style quite confusing to understand. So I thought it would be
 nice to have something like:
 
 if ( key==value ) { includes or style rules }
 
 I think such a if-clause would also in general makes style-files a
 little bit more readabel and shouldn't be that complex to implement
 (or am I wrong?).
 
 What do you think about such a if-clause? Maybe there is a better
 way for it.

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

iQEcBAEBAgAGBQJTM9JDAAoJEPFgsWC7jOeTtzgIAIemvaXqXmSiR4G5p3DqaeCB
Z/xjbDHOp81KebkDmh36f3s+zpewPPhNusOb1H4qTT27xevXGvBeDMkbYLCpnkoO
Kdt+Ej9V5Bosmc6Yey0vs2uClAIC+2OUTXoulh2ZWy/3W4aYAJdtbIQH5IGPgUhY
Lh4N77bvIxfQck7fEDbCtxbjuLd56Z0zASO65kAGwo9OPjyWBHYbkZBMS/IBpdyp
pTTD89Gqf4MXgi6v1bHw/n/ePVD8l/4oV/p86mAtyUVaQk332YQr9Qoryq4PuDlY
XGPvPiuGk8waqsl2ZtZyEh7m7y2Zb8njBuHC2gKguqEzNjnsgjbIy4Heg26yI6E=
=O67V
-END PGP SIGNATURE-

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

Re: [mkgmap-dev] conditional includes in style

[Henning Scholland]

Hi Gerd,
maybe it gets a little bit clearer if I gave an example.

if ( mkgmap:country=DEU ) {
include 'deu_highway_rules';
}

or

if (mkgmap:country=DEU) {
highway=primary { set mkgmap:access=no }
highway=... {...}
...
}

Henning

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

Re: [mkgmap-dev] conditional includes in style

[Henning Scholland]

Hi Felix

Am 27.03.2014 19:59, schrieb Felix Hartmann:
 That is also quite nice, my main problem with this approach is - can we
 by now assume that the mkgmap:country tag is 99.9% available correctly
 when using precompiled bounds?

I haven't heard about any complaints about this.


 if not passing options from commandline is in this case more reliable -
 because if you know that you only have input from one country, then give
 options on commandline aobut include - and not read a tag from data.
 Also I would suppose this is quicker.

I would assume it's quicker. But I'm also publishing my style and other
people will (maybe) render a map of an region. It's a lot of easyer for
them to just use the style, don't care about the region, instead of
needing a option to set. Can you explain there is the difference between
include in options-file and two or more styles? Via include you can
create a header-style which only uses include. Eg.

ger/lines
include(adresses;)
include(access;)
include(routing_ger;)
include(foobar;)

 Of course if you build a Europe map, or another multi country map - then
 better use from the style. But that's exactly why actually both
 conditional includes would be useful.

If you build maps, which are not just country-maps, you'll need an
style-based thing. But I can understand, that performace is a good
argument. So I agree both is useful. But thinks like default-name or
something like that shouldn't be set in options.

Henning

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

[mkgmap-dev] NPE with r3183 r3185

[Henning Scholland]

Hi everybody,

since updating to r3183 I get the following NPE. Also Updating to r3185
doesn't solve the issue to me. The NPE doesn't occur in all my maps, but
in several ones, mainly in maps with higher density of mapping.

Henning

java.lang.NullPointerException
at
uk.me.parabola.mkgmap.reader.osm.RestrictionRelation.eval(RestrictionRelation.java:106)
at
uk.me.parabola.mkgmap.reader.osm.RelationStyleHook.end(RelationStyleHook.java:56)
at
uk.me.parabola.mkgmap.reader.osm.OsmReadingHooksChain.end(OsmReadingHooksChain.java:79)
at
uk.me.parabola.mkgmap.reader.osm.o5m.O5mBinMapDataSource.load(O5mBinMapDataSource.java:49)
at
uk.me.parabola.mkgmap.reader.osm.OsmMapDataSource.load(OsmMapDataSource.java:127)
at uk.me.parabola.mkgmap.main.MapMaker.loadFromFile(MapMaker.java:167)
at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:63)
at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:220)
at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:216)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)

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

Re: [mkgmap-dev] NPE with r3183 r3185

[Henning Scholland]

Hi Gerd,
so how I have to change my style to get the same effect as I got before?

Henning

Am 13.04.2014 17:39, schrieb Gerd Petermann:

Hi Henning,

yes, these two lines are problematic:
type=restriction  except ~ '.*bicycle*.' { delete type ; delete 
restriction }

type=restriction:bicycle { set restriction = '${restriction:bicycle}' }
mkgmap ignored them up to release r3169, now they have an effect. I'll 
add checks to detect that.


Gerd


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

Re: [mkgmap-dev] mkgmap ToDo list

[Henning Scholland]

Am 16.04.2014 22:01, schrieb GerdP:

Why do you think that it is a bug?
Think about oneway=-1 and in style you add oneway-arrows (link mapnik 
does). In style you will handle -1 special, because arrows should drawn 
in oposite direction of way. If mkgmap now changes direction of the way, 
arrows should be in wrong direction, or am I wrong?


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

Re: [mkgmap-dev] barriers on major roads

[Henning Scholland]

Hi Gerd,
in most cases you will be correct with your assumption. But I cannot say 
for sure, that there isn't a case outside in reality, for which the 
tagging on crossing node is correct. So I'm not sure if ignoring would 
be helpful in every case.


Maybe it would be a better thing to generate for such osm-bugs 
gpx-files, which contains the bugs. So it would be easy to fix them.


Henning

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

Re: [mkgmap-dev] what makes a way a road?

[Henning Scholland]

Am 23.04.2014 08:03, schrieb Gerd Petermann:
Is this intended? 

I don't think so.

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

Re: [mkgmap-dev] mkgmap ToDo list

[Henning Scholland]

Hi @ all,

while thinking about creation of simple maps with less features I 
thought about an better parameter for splitter then just the number of 
OSM-nodes. Actually splitter writes density-files (but also based on 
OSM-nodes). You can imagine that the number of OSM-nodes may differ a 
lot in detailed mapped areas if you just want to generate a map of 
highways. Maybe it would be a great feature, that mkgmap can write a 
density-file (as splitter did) but also considering the used style file.


Henning

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

Re: [mkgmap-dev] mkgmap ToDo list

[Henning Scholland]

Hi Gerd,
splitter is able to write a density file, which stores the density of 
OSM-nodes in the specific area. Afterwards the file is splitted and 
processed by mkgmap. mkgmap will use only the objects, which are 
addressed in style-file.


Example: In a rectangle of 100x100m are 5 nodes belonging to a highway 
and 10 nodes belonging to POI, and polygones and style-file only 
contains highways, mkgmap writes only 5 nodes (and one line) to img-file.


For an more effictive splitting of tiles I would imagine, that a 
density-file created by mkgmap based on the written data will be much 
better then the file written by splitter.


Henning

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

Re: [mkgmap-dev] mkgmap ToDo list

[Henning Scholland]

Hi Gerd,

finding a proper max-nodes value wont solve the problem globaly. Eg. 
then you compare the needed value from europe/north america to the value 
needed in the rest of the world.


Henning

Am 25.04.2014 19:35, schrieb Gerd Petermann:

Hi Henning,

well, I don't know how well the number of nodes
in a tile correlates with the size of the img file,
but it seems to work for most users.
My understanding is that this should work as well for
a style which only processes a few details,
only the ratio between number of nodes and tile size
will be different, in other words, you have to find
out how much higher the max-nodes value can be.

Gerd



 Date: Fri, 25 Apr 2014 19:27:09 +0200
 From: o...@aighes.de
 To: mkgmap-dev@lists.mkgmap.org.uk
 Subject: Re: [mkgmap-dev] mkgmap ToDo list

 Hi Gerd,
 splitter is able to write a density file, which stores the density of
 OSM-nodes in the specific area. Afterwards the file is splitted and
 processed by mkgmap. mkgmap will use only the objects, which are
 addressed in style-file.

 Example: In a rectangle of 100x100m are 5 nodes belonging to a highway
 and 10 nodes belonging to POI, and polygones and style-file only
 contains highways, mkgmap writes only 5 nodes (and one line) to 
img-file.


 For an more effictive splitting of tiles I would imagine, that a
 density-file created by mkgmap based on the written data will be much
 better then the file written by splitter.

 Henning

 ___
 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] mkgmap ToDo list

[Henning Scholland]

Hi Gerd,

I would like to have img-tiles which have globally nearly the same 
filesize, so that they use the space of devices like eTrex 10.


With my actual map I use globally the same value for max-nodes. But the 
size of the img-tiles differ more then factor 2. Eg. a tile in Germany 
is between 2 and 5 mb where a tile in China is about 10 mb. If I remove 
details, this difference will increase, because in Germany more objects 
will be removed from the img-tile then in China.


Henning

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

Re: [mkgmap-dev] mkgmap ToDo list

[Henning Scholland]

Hi Lambertus,

are these numbers the result of your script or the basic results of 
splitter?


Henning

Am 29.04.2014 20:48, schrieb o...@na1400.info:

I don't have the number for Germany, but perhaps the world suffices?

The image size distribution of my generic map is:
2MB   some
2-3MB  260
3-4MB  410
4-5MB  600
5-6MB  580
6-7MB  390
7-8MB  250


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

Re: [mkgmap-dev] r3239 in performance2 branch

[Henning Scholland]

Hi Gerd,

below you'll find the compared times, mkgmap needs to compile the map.
From o5m-tile til img-tiles and gmapsupp.img. Seems to be, that you
are on a good approach.

Henning



trunk   branch  
Germany 2110335 1830965 -13,24%
Turkey  150734  137633  -8,69%
Scandinavia 668798  647888  -3,13%
Poland-Czech721500  663320  -8,06%
BeNeLux 539420  495979  -8,05%
Patagonia   322421  308895  -4,20%
MiddleAsia  60273   57082   -5,29%
Alps1866317 1724296 -7,61%
NewZealand  328242  288148  -12,21%
GreatBritain701715  658821  -6,11%
Arabia  268545  259366  -3,42%
Canada-SW   369874  340675  -7,89%
China   181014  163815  -9,50%
India   184368  169392  -8,12%

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

Re: [mkgmap-dev] r3239 in performance2 branch

[Henning Scholland]

Hi Gerd,
I also tested with r3245. For some regions this is even slower as
r3225. But in general, it will save me (or lets say better my pc) a
lot of time.

Henning

r3225   r3239   r3245   
Germany 2110335 1830965 1775142 -13%-16%
Turkey  150734  137633  133942  -9% -11%
Scandinavia 668798  647888  647349  -3% -3%
Poland-Czech721500  663320  660533  -8% -8%
BeNeLux 539420  495979  501059  -8% -7%
Patagonia   322421  308895  324119  -4% 1%
MiddleAsia  60273   57082   51164   -5% -15%
Alps1866317 1724296 1688913 -8% -10%
NewZealand  328242  288148  287371  -12%-12%
GreatBritain701715  658821  601403  -6% -14%
Arabia  268545  259366  235044  -3% -12%
Canada-SW   369874  340678  317670  -8% -14%
China   181014  163815  164700  -10%-9%
India   184368  169392  149435  -8% -19%




Am 30.04.2014 19:10, schrieb GerdP:
 Hi Henning,
 
 r3245 should be good now, faster and no known errors. I've also
 applied the oneway patch.
 
 Gerd
 
 
 
 Henning Scholland wrote
 Hi Gerd,
 
 below you'll find the compared times, mkgmap needs to compile the
 map.
 From o5m-tile til img-tiles and gmapsupp.img. Seems to be, that
 you
 are on a good approach.
 
 Henning
 
 
 
 trunkbranch Germany  2110335 1830965 -13,24% Turkey  
 150734
 137633   -8,69% Scandinavia  668798  647888  -3,13% Poland-Czech
 721500   663320  -8,06% BeNeLux  539420  495979  -8,05% Patagonia
 322421   308895  -4,20% MiddleAsia   60273   57082   -5,29% Alps 
 1866317
 1724296  -7,61% NewZealand   328242  288148  -12,21% GreatBritain
 701715   658821  -6,11% Arabia   268545  259366  -3,42% Canada-SW
 369874   340675  -7,89% China181014  163815  -9,50% India
 184368
 169392   -8,12%
 
 ___ mkgmap-dev
 mailing list
 
 mkgmap-dev@.org
 
 http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
 
 
 
 
 
 -- View this message in context:
 http://gis.19327.n5.nabble.com/r3239-in-performance2-branch-tp5804618p5804744.html

 
Sent from the Mkgmap Development mailing list archive at Nabble.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

Re: [mkgmap-dev] r3251 in performance2 branch

[Henning Scholland]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



Am 02.05.2014 23:21, schrieb Gerd Petermann:
 Hi all,
 
 please test / review the changes in the branch, because I don't
 plan any further optimizations for now. You should see no different
 output compared with r3248 in trunk, but around 15% faster
 execution time and also a reduction in peak memory usage.

For me it seems to be a great improvement.

Henning
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)

iQEcBAEBAgAGBQJTZJ4nAAoJEKXggIeC16WPzp8H/A2wrljfP2wamkT0bAvTLq3A
b4CWMJP5kQHNukgP6KNCtiEIf9/aDnlKJ36Z2c14NNnIQI6/9PMwVcqSn1C2gfh3
NAd/qhbc+3Syr8P9mqVLoP1OFT8OCqTGjSqbBhdN3Qaqa+bDuD6Mj2Th1H85w0pz
kEGjIagjNlrRRuvLkkjXJiRykc9Rxtp5mMB2aSNvGH9g/nb8Dhi9E/airp+pji6+
SwqqMuOe88FnYFiIgiidp0QSvWNwI4lt05572wmIvE9sDGRVfe9zYEzAM9mMRnFn
bNSl0ZjVbZuPIz0gBzdGq7wwh7VIHzma5JBIr4tFNMRs3y+6Lyvu7ecJBCBiuwg=
=iSDS
-END PGP SIGNATURE-

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

[mkgmap-dev] splitter removes multipolygon-tags

[Henning Scholland]

Hi @ all,

some users of my map reported to me, that there are several polygons 
missing. After taking a look into the splitted o5m-files I can confirm, 
that they can't be rendered because the objects doesn't contain the 
necessary tags.


First I thought, it could be cause because of multiple input-files or 
garbage input, but I can reproduce it also with a fresh planet, only 
converted to o5m. So I assume that input-data is ok and it is not 
depending on multiple input-files.


I've uploaded a tile http://www.aighes.de/data/mkgmap/1211.o5m

http://www.openstreetmap.org/#map=15/49.8764/11.5338 For example this 
forrest is missing.


I haven't tryed with new splitter-r325, but I don't think it will change it.

Any ideas what could caused the problems?

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

Re: [mkgmap-dev] splitter removes multipolygon-tags

[Henning Scholland]

Hi Gerd,
sorry for delay. I've continued investigation. If I only split the 
single tile (6211), everything seems to be fine.


single tile:
http://www.aighes.de/data/mkgmap/6211.o5m
http://www.aighes.de/data/mkgmap/splitter_6211.log

all ~1500 maptiles at once:
http://www.aighes.de/data/mkgmap/1211.o5m
http://www.aighes.de/data/mkgmap/splitter_1211.log

Henning

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

Re: [mkgmap-dev] splitter removes multipolygon-tags

[Henning Scholland]

Am 07.05.2014 11:24, schrieb GerdP:

I noticed that relation 70724 is missing your file,
so we are not talking about removed tags here.


Hi Gerd,
I'm sorry for this. My first thought was, that splitter transforms MPs 
to areas. But of course this was stupid. Correct is, that there are 
missing some relations.


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

Re: [mkgmap-dev] splitter removes multipolygon-tags

[Henning Scholland]

Am 08.05.2014 08:38, schrieb Gerd Petermann:

Hi Henning,

I tried with the areas.list from your homepage. It is not exactly like
the one you used to produce the log, but I was able to reproduce
the problem.
It is caused by overlapping tiles in this area.
I am now looking for a correction.


Hi Gerd,
thanks for taking a look into it. I'm actually let splitter and mkgmap 
do their jobs and will take a look into the maps tomorrow.


Henning

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

Re: [mkgmap-dev] splitter removes multipolygon-tags

[Henning Scholland]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Gerd,

after taking a deeper look into my tile 1211 (also with r327),
there are stil mp's missing. Eg. three buildings of Bayreuth
University. All three buildings are mapped as mp and also are member
in a site relation of the university.

After splitting all three mp (8628, 5185 and 1869778) aren't written
but relation 933537 is written.

I also updated my files on github, if you need them.

Henning
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)

iQEcBAEBAgAGBQJTbTSfAAoJEKXggIeC16WPhPQIAISLb9pzkWfsytgu44WmC6Fn
LRMRfeup8RcLGzbJbxD8trM4r1dUuhy9vCAzhLPzbEq+ojfw+GeKydPBwGOx9kSF
AxpELMvhAHlCr6s3nv+iTehsWf2N6ivJA2TMRPtBJil2Zabe2OkgVnji6DnPyhUO
egD1kM5PEaOx6diELEbHGPc3UCwYiJ24ANTCoV+o6GKb2tPsJnebdE8XsN17BL6X
/wG8w+Srbkgiu4nCDvG0hDNA/gZkZF6i4K1CMGinoUtpVyR58BYUKbsUdVqRDOvc
VmCgj3jyi7vC4bt03rgUR9ADrNZIvVojj3N+cH7YX3/eHKUX3xVY7iTauaPfnrk=
=OWHv
-END PGP SIGNATURE-

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

Re: [mkgmap-dev] splitter removes multipolygon-tags

[Henning Scholland]

Thank you Gerd,

I will give it a try. Does it work now for as many overlapping tiles as 
possible? Otherwise it would be helpful to write a warning, that too 
many tiles are overlapping, which can lead to missing objects.


Henning

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

Re: [mkgmap-dev] splitter removes multipolygon-tags

[Henning Scholland]

Hi Gerd,
ok, so my next step will be to optimize my tiles.

Henning

Am 10.05.2014 17:27, schrieb GerdP:

Hi Henning,

I did not try what happens when 5 tiles overlap the same point,
but it should work.
As I said, you should try to avoid that, as each tile will
require the complete reading of the input file.

Gerd


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

Re: [mkgmap-dev] splitter removes multipolygon-tags

[Henning Scholland]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Gerd,
this is, what I'm thinking about to do, but on the other hand I'm
loosing the actual flexibility. I think I will give it a try and will
see, how it works.

Henning

Am 11.05.2014 08:24, schrieb Gerd Petermann:
 Hi Henning,
 
 If you don't mind to have a map of e.g. Germany which also
 contains small parts of other areas, I think the fastest way is
 this:
 
 combine your *.poly files so that you have one henning.poly that
 contains the areas for which you want to create maps. Execute
 splitter with --polygon-file=henning.poly --max-nodes=... 
 --stop-after=split --write-kml=splitter.kml planet.o5m
 
 If you have an actual densitites_out.txt for planet, you can also
 copy it to the working directory and rename it to densities.txt.
 Splitter will use this file instead of reading the planet.o5m, and
 the program finishes within seconds.
 
 As a result you have a kml file and an areas.list. The next step
 would be to re-combine the areas so that they build the maps that
 you want to create.
 
 If you need the same tile for two maps, but with different mapids, 
 I suggest to copy the output file of splitter. Maybe a small
 script is needed to perform this step.
 
 Gerd
 
 
 
 
 Date: Sat, 10 May 2014 20:31:51 +0200 From: o...@aighes.de To:
 mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] splitter
 removes multipolygon-tags
 
 Hi Gerd, ok, so my next step will be to optimize my tiles.
 
 Henning
 
 Am 10.05.2014 17:27, schrieb GerdP:
 Hi Henning,
 
 I did not try what happens when 5 tiles overlap the same
 point, but it should work. As I said, you should try to avoid
 that, as each tile will require the complete reading of the
 input file.
 
 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
 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)

iQEcBAEBAgAGBQJTbzjnAAoJEKXggIeC16WPQ3EH/3oEqaqPa4JrZj8ovd+6m6/C
rS7xtBNNA47tMVOMqwUuamcg1rWS/oHyfxhougR8gMfupui6P0iIqMh2pceKcvN/
VmzTIjFLABEfqmJ0GkRZ098VI4aERZ+GaEoM7gKO7VWbgPDRnB7nAaofk6XwoaTp
ga+kIdYIiFENedDD407TqQpBMfu9YTfssLwba8G7iwSAHE7eWQKYeKSVd+hu1AlA
r/JxcEHfQOP/SdqicOIs7yqRYqtnFtKneZczWgceL9MMIkEvwj8z/MCBI/BrFmqt
iQCdL1g+vdzoDVnvvcB0GbBpdhwPTHQ6/6oAx6JKo5C1QZlT+t6En6wLkQ1DK7U=
=cuZR
-END PGP SIGNATURE-

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

Re: [mkgmap-dev] splitter removes multipolygon-tags

[Henning Scholland]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Gerd,

the flexibility is, that I actually can just add new areas to my
areas.list and don't have to care about anything. If mkgmap throws out
a warning about too many nodes in a tile, I let splitter create a new
areas.list for the region and I can continue.

In the new workflow I then have to adjust the script, which copies the
multiple used tiles.

It would be very helpful, if splitter can do the copying of tiles.

Splitter detects overlapping areas in areas.list and handles these
regions as a own polygon and is writing tiles for each map, which
touches the overlapping area.

So for example, if a split a map of Hessen (1000) and a map of
Germany (1100), splitter will use a polygon of Germany with a hole
at the place where Hessen-poly-file has a coverage and Hessen-polygon.

So the resulting areas.list could looks like:

1101;1001: 
1102: 

So splitter is able to write the data of a tile in Hessen to the map
of Hessen and to the map of Germany.

Maybe such a system is a better and more robust solution then handling
overlapping tiles. But I don't want to made you code that only for me.

Henning


Am 11.05.2014 10:49, schrieb Gerd Petermann:
 Hi Henning,
 
 can you describe what flexibility you are loosing? Could splitter
 be improved ?
 
 Gerd
 
 Date: Sun, 11 May 2014 10:46:31 +0200 From: o...@aighes.de To:
 mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] splitter
 removes multipolygon-tags
 
 Hi Gerd, this is, what I'm thinking about to do, but on the other
 hand I'm loosing the actual flexibility. I think I will give it a
 try and will see, how it works.
 
 Henning
 
 Am 11.05.2014 08:24, schrieb Gerd Petermann:
 Hi Henning,
 
 If you don't mind to have a map of e.g. Germany which also 
 contains small parts of other areas, I think the fastest way
 is this:
 
 combine your *.poly files so that you have one henning.poly
 that contains the areas for which you want to create maps.
 Execute splitter with --polygon-file=henning.poly
 --max-nodes=... --stop-after=split --write-kml=splitter.kml
 planet.o5m
 
 If you have an actual densitites_out.txt for planet, you can
 also copy it to the working directory and rename it to
 densities.txt. Splitter will use this file instead of reading
 the planet.o5m, and the program finishes within seconds.
 
 As a result you have a kml file and an areas.list. The next
 step would be to re-combine the areas so that they build the
 maps that you want to create.
 
 If you need the same tile for two maps, but with different
 mapids, I suggest to copy the output file of splitter. Maybe
 a small script is needed to perform this step.
 
 Gerd
 
 
 
 
 Date: Sat, 10 May 2014 20:31:51 +0200 From: o...@aighes.de
 To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re:
 [mkgmap-dev] splitter removes multipolygon-tags
 
 Hi Gerd, ok, so my next step will be to optimize my tiles.
 
 Henning
 
 Am 10.05.2014 17:27, schrieb GerdP:
 Hi Henning,
 
 I did not try what happens when 5 tiles overlap the same 
 point, but it should work. As I said, you should try to
 avoid that, as each tile will require the complete
 reading of the input file.
 
 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
 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)

iQEcBAEBAgAGBQJTbz+xAAoJEKXggIeC16WPKt8H/2HpxreZGM/qZTgx54DFTLis
QvVmsIy2reNNbDa/FAY5Kf/983chPbJ0jyu72bkIqcdOQ2HRIxRxlTwbEGHLYQsB
ZoZBJkB/8OhrcRb6fEfdqQiEtZdptliPD3VQ08WwqxK5h8QDj/raJTHHPtzpC+7I
pmFbkU7Ci4KdFTH6iazGLQWJ6r3cSHkddrL988fi86CYaLWxv/Gtj4DXnjASWKGa
jc1tO9c4yyAn+/hK9UPyCqrJgvgunSlmTDLX1acC/DZKXeQXU8sPbKz16gr0Vj4o
GBgUM3JI5LelCxD4Sq8SyD9+3aXQ+2ykHLyyO6rgExwrmmP4aJaQBLJUu/7AE58=
=r5q6
-END PGP SIGNATURE-

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

Re: [mkgmap-dev] splitter removes multipolygon-tags

[Henning Scholland]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Gerd,

it would be enough, if one tile is only written ones to Disk and only
linked via template.args. I think this is the better way for
SSD-lifetime and speed. Debugging should also be possible.

Henning


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)

iQEcBAEBAgAGBQJTb1idAAoJEKXggIeC16WPSD4IANVRTZ54T104OEebgrNjGg6D
V1MejMctZJotBQAr7ndLIpMkFxt6t6EXeUGaAXLEdwv24nIt7mto3XtmC7Ixfcwm
D0x8klhib2DD0whc9RR0MSjQtfgvamYtT/tHlYOuakbA2cfylPRkQjL5VjFPzTI5
rUt7LRvb5jMo1HL3JKCC49TJRnZXMBVxIrS15AnQr9OYkJluv/wdmhh9OWKnw23Q
9rwqv9m/AIAHajvEIQRUEE2Tk5Tcld+ruFy3gPSF6Q1nSbzCg+77ejYSU7tO4G4S
a8vsN0exvZLkplRr55YcKITMYky+2euX0gWmZ0iF5lDlOItNi0JehuVcTCopT0c=
=CPGd
-END PGP SIGNATURE-

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

Re: [mkgmap-dev] splitter removes multipolygon-tags

[Henning Scholland]

Hi Gerd,

wow, that was quite fast!

I called splitter like that:

java -Xmx8G -XX:+UseCompressedOops -XX:+UseParallelGC -jar
./bin/splitter.jar --max-threads=6 --stop-after=split
--polygon-desc-file=./resources/areas.osm --status-freq=0
--max-nodes=120 ./data/planet.o5m ./data/srtm.o5m

As a result I got an areas.poly, areas.list and density-out.txt, but no
template.args-files. The poly-file looks much to large compared to the
input-osm-file. Maybe I did something wrong?

input and output: http://www.aighes.de/data/mkgmap/splitter_out.zip

Henning

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

Re: [mkgmap-dev] splitter removes multipolygon-tags

[Henning Scholland]

Hi Gerd,
r333 outputs the files needed. But the resulting poly-files are not 
quiet useful. Eg. a part of Germany and BeNeLux reaches til the northern 
part of Scandinavia. Most asian maps are much larger then original files.


Henning

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

Re: [mkgmap-dev] splitter removes multipolygon-tags

[Henning Scholland]

Hi Gerd,

unfortunately no tool, so I will do it manually.

Henning

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

Re: [mkgmap-dev] splitter removes multipolygon-tags

[Henning Scholland]

Hi,
I've written a little formula in Excel if someone is interested in:

=VERKETTEN(RUNDEN(RUNDEN(LINKS(WECHSELN(A1;.;,);FINDEN( 
;WECHSELN(A1;.;,)))*(2^24/360/2048);0)*2048*360/(2^24);6); 
;RUNDEN(RUNDEN(RECHTS(WECHSELN(A1;.;,);FINDEN( 
;WECHSELN(A1;.;,))-1)*(2^24/360/2048);0)*2048*360/(2^24);6))


Paste in Cell A1 the string of josm-function, which allows you to move a 
node to a coordinate and copy back cell B1.


Henning

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

Re: [mkgmap-dev] splitter removes multipolygon-tags

[Henning Scholland]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Gerd

Am 13.05.2014 22:44, schrieb GerdP:
 This is an error in splitter, I have to fix that.

Maybe you can also change the name of the generated kml-files.

name-.areas.kml isn't quite good. At lest the first dot should be
removed. But I think best is just to name them name.kml

Henning
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)

iQEcBAEBAgAGBQJTc4voAAoJEKXggIeC16WPFNAH/0wep5VuXi+eSOb+A0eK6DZR
viTX5/Ms+zLINQF8dPFE3XMI9LGIs5tXYJyD00nc2StBP3vpSprizDK/wb8byrEf
HexC5CbGSCzZWQo5EHDp6Es8Ic+1wF+7vQ96PbWH9NkE7MWekNKEeSTReqnsWcQD
oSnc2IVKBlvZ8L524Gq4gB3/b19K3AmGKWs99kA7YNu7ynURv/mQU5+EETIwIdbu
V57DY5LALw35pFNt9lGpCpyYplpcUrLYqLgFiRPfdTpMShGQHOH8YJVTl+WLZFYT
v77biIZhkv5MtLKWFuP8/FLl1VpBT5b9DwcF8d3QFizX3yF35fNGD4BSR67Fj8U=
=B3Ya
-END PGP SIGNATURE-

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

Re: [mkgmap-dev] error handling in splitter

[Henning Scholland]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Gerd,
I would agree, that if input-data cannot be read or tiles cannot be
written, splitter should stop and write an error-message.

A special log shouldn't be required if this log will only contain
stdout and/or stderr. This can be written to a file by cmd.

Other things could be done:

As you mainly had written the overlapping-code for me, I think it can
be removed. The new method is so much better, that I would highly
recommend not to use the older one.

Splitter and mkgmap are using different libs of fastutil, osmpbf and
protobuf. Maybe it would be a good thing to let them use the same libs.

Henning

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)

iQEcBAEBAgAGBQJTc5NeAAoJEKXggIeC16WP/lMH/iMIHOpOoiCKZLqxf0sdwATy
afRs/I1V1bg+lht8oQrgCHju1jLOQIiBAxHyATlsNUvJ2rS8jhcy+wmwF+AvxKxw
x+BaD+KNbJDzq3Jj6Ll0O3VO556UVYWUv1jNr7YBU7omv0774H4vgejVsnykt0/x
g8bnqU/jGpOJwcRuf+xt4HSrhF287+Dsm/dgCaGIOLeUGiz1KDVA1PwkpqyRJ467
cdJEwK2y43BYCzTIspyr3fCaAcc4EHLm1n9NL0EfUV5S3W3solIxrFj0H+RnxKlU
hlYTMIi0suxWqL2xTOTGlmzAf7emFHMk0ofLv/fi8/vmAlI2ajzZpRACr0l6wbI=
=2EMX
-END PGP SIGNATURE-

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

[mkgmap-dev] path in template.args-file

[Henning Scholland]

Hi,
I just realized that the paths in the template.args file is interpreted 
by mkgmap as relative to template.args file. Is this behaviour intended 
or shouldn't it be relative to the path, from which mkgmap is called 
from, as every other path in mkgmap?


The template.args-file is pretty old, so maybe changing the behaviour 
isn't that good. But maybe mkgmap could first look for the file relative 
to template.args file and if there is nothing found then in the file, 
where mkgmap is called from?


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

Re: [mkgmap-dev] splitter and overlapping tiles in split-file

[Henning Scholland]

Hi Gerd,

I plan to document in a few sentence, what you should do, if you are 
having overlapping polys. This could be integrated in mkgmap-guide. But 
I don't know til then I can finish it, because next weekend I'm starting 
a short biketrip (just a week) and I wont have time before.


Best situation would be: Insert warning now and if next time something 
changes in splitter, which needs some tweaking in this section, remove it.


Henning


Am 16.05.2014 08:25, schrieb Gerd Petermann:

Hi all,

 Other things could be done:

 As you mainly had written the overlapping-code for me, I think it can
 be removed. The new method is so much better, that I would highly
 recommend not to use the older one.

The code for this is not big (maybe 200 lines), but in the past
it often caused trouble when new features were implemented,
and it is difficult to test, so I'd appreciate to remove the support
for overlapping tiles in a given split-file.

Is it okay to remove the support and print something like
Error: Support for overlapping tiles in split-files was removed in 
version r36x.

or should splitter print a warning to stderr like
Warning : Support for overlapping tiles will be removed in future 
releases

for a while ?

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] splitter r383

[Henning Scholland]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Gerd,
go for it!

Henning
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTei7jAAoJEKXggIeC16WPvnEIAMR5y2LT4dU8LrfYIpAun97d
N4kenezcxHXg8h89MmuaY7p9iIaMCHSmHQQr9QdQ6YYOcEQ5zH9fNY3X8q3W9Vc3
gnQfCs1ekFvcFv4rpayVAs422R2YhM/739eCQ53BkB72SbY98oh9OUVOFzfVyFZO
jQuWEW9ofWquWg4HB/d7xHimQdxcEP6dZOLNT3QnwUBX6biIUI40XyyH6a4jGm7e
Vq7JLclqLhoVr6pw45mcSc4jBm8zDh1gNkiuAYO+gQsJlkRdzxdjjxJYzPvcAQ0O
0F2gM9oYWiAdBXkk56URflbj49pZC6qUhtwI7KU9p74z7bxcJTnmsvYf7ogIrwM=
=K+92
-END PGP SIGNATURE-

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

Re: [mkgmap-dev] how to replace false tracktype keys in style file?

[Henning Scholland]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,
what about: \w*[1-5]

some alphanumeric characters and then one number between 1 and 5.

Henning

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTgIbkAAoJEKXggIeC16WPBqQH/jQJ32R4hyJt98DFuSQeR/RM
XX2J4c20VmRJfIRhhrS+T1MiWEP2q/sleeGY/sls5/K7pcZbdffMbhv14wnGWO5t
O7MY2sO+8J1mE3LEdTvUlkvZWMnurpkv6gJqbEQqfsqj3cRJH0Xy39HKWyL8jAB8
mtTvOFG5aDsglUhetGRNe61sIHKczTkQIBwTjtAzNq2o5jtNTaVGAlnYB+ikI//s
kRaRW/a8j8tSUFY64oSbdDsAMKVq13NLXlgJYbsNtye44NyynoimMEYUFh6kYtGc
qCNUyohYk40uqtXFcXef9d6mn7RsFyBgt0yV/iWosobYhWq2awc/l9tn36f7IFQ=
=Xn/3
-END PGP SIGNATURE-

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

Re: [mkgmap-dev] help needed

[Henning Scholland]

Hi Gerd,

as I got it right, in nearly all typical cases the fast algo would be ok
because the error is pretty small. So what about calculating always the
fast algo and if the calculated distance is larger then X, mkgmap
calculates the distance again with the more precise algo.

Henning

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

[mkgmap-dev] Rendering of emergency access points

[Henning Scholland]

Hi everybody,

today I received an eMail from Niedersächsische Landesforsten (a
governmental organisation for forestry in Germany) about actuality of
emergency access points. Don't know what they want exactly, but I think
I'm not the only one who is rendering these points.

So did anyone else received such an eMail?

Henning

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

Re: [mkgmap-dev] How to display highway shields with numbers only

[Henning Scholland]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Mark,

take a look in Table 4.3 some lines above the shields are explained.
There you'll find subst and part. They will help you.

Henning

Am 09.12.2014 um 03:51 schrieb Mark Bradley:
 Hi list members,
 
 
 
 I'm relatively new to mkgmap.  I have a question about displaying
 shields on highways.  Table 4.4 in the Conversion Style Manual
 shows highway shields displaying numbers only, which is what I
 would like to achieve.  In Table 4.3 (the list of substitution
 filters), the description for the highway-symbol filter says that
 the filer Prepares the value as a highway reference such as 'A21'
 'I-80' and so on.  A code is added to the front of the string so
 that a highway shield is displayed, spaces are removed and the text
 is truncated so as not to overflow the symbol.  The description
 does not explain (from what I can tell) how to remove the
 alphabetic characters, leaving only the numbers.  I've tried
 several possibilities of the filter without success.  Where I live,
 there's a motorway called Interstate 70 which is labeled I70 in
 OSM.  I would like to create shields with only the number in the
 shields, similar to the example in Table 4.4.  How do I do this?
 
 
 
 Mark
 
 
 
 
 ___ mkgmap-dev mailing
 list mkgmap-dev@lists.mkgmap.org.uk 
 http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
 

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

iQEcBAEBAgAGBQJUh1dIAAoJEKXggIeC16WP4ncH/2HnLscBCUuF0QicLv61mC+5
y+xCf74G39ddSCMO+GHnZmqx9m0qUO951CRiXQkwlNSJuN28qUlqwC2eQNa02YOs
azD6HkkeqlYh9fv6QCQKrQMpcB5OtcPR/l0QMkkGQ10dB5P3VAicBSDRlF1XW2wT
XPXO6+PLlPjxDeix4RS5BY/lJh5WoxLvec4brada9ECfQPIc+MkSvG7BsN4rV95U
FDCkQCz54hEJpWu0j6nFQlKOsvXmusi/2cE5uFo/Wc7inzmShTa6kjuJqK7FBNyS
gAeVYLCIlnybXGciFKMJXkqHximYGL5t2lnQ0rthOkhLEVPvR6PKPopMhoW5g4c=
=CPn9
-END PGP SIGNATURE-

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

Re: [mkgmap-dev] A few thoughts on non-rectangular tiles

[Henning Scholland]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Gerd,

I would suggest that a common osm-file format would be the easiest way
for most of the users (who generating maps out of osm-data and are
used to josm).

The next question is: Should there only be a non-rectangular border of
the hole map or for each tile?

Eg. If I want to have a map of Germany with the shape of Germany and
also tiles shaping the federal states (Bundesländer), it would be
necessary to tell splitter or mkgmap in the end what is outside border
and which borders are inside the map. Or am I wrong?

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

iQEcBAEBAgAGBQJUlUzWAAoJEKXggIeC16WP+18IAOIvzYYLV+G7d5cW9500uKpf
CSY8EGRtL5JTfjIC/8hXdO5JzIMQhjBKxXNfkzrCQLZCBLqKlvisdDtaI18UcL9i
JtaVP0Q55O7kdmIdQVPoE0J1CASKOfMjnscECmv7wpeWgv31dD/pJjCn/KC0shRj
tIkCQogGN1k82B6KzitCv8xZVjyGpNlS6CbWlpX7oSxMN63mSmzXkmuZ12F5Usi6
HUyLwMZ2F52TuQZTSpZGH9+y8Y7FuXy/giI+YTqGY8rFJSKUaWcI4AgtTlt9FWZq
PMdNRSSCvhIFUDn1SMS4WP3nZBeSy7FYiMaMt0xez/3XUW55bQEbYa3JfnOs9ik=
=VOWf
-END PGP SIGNATURE-

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

Re: [mkgmap-dev] mixed index branch merge

[Henning Scholland]

Am 16.02.2015 um 14:05 schrieb Gerd Petermann:
 Hi Steve,
 
 I fear I don't understand what problem you see
 with roads like 'The Avenue'
 My understanding is that we put the full name into the
 index, so the road can be found. On the other hand,
 nobody would expect to find this road by typing
 just avenue, right?

I don't think so.

Think about The Avenue and Greenwich Avenue. The first one I would
expect to find by Avenue, the second one not. But I think there could be
hard stop-words and soft ones. So first the hard once like The or
Straße will be removed. Soft stop words will be only removed if there
are other parts in the name.

Another possibility could also be a white list for such combinations.

Henning

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

Re: [mkgmap-dev] mixed index branch merge

[Henning Scholland]

Hi Gerd,
I would prefer kind of such a solution. Maybe if this list is generated
after processing mkgmap:country the country could be also used, so
having a list for each country. Of course it would be nice to have the
list written to a file and also give mkgmap a specific list.

Format could be something like:

[DE]
Straße
Weg

[US]
Drive
Street

Bye
Henning

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

Re: [mkgmap-dev] POIs without POI-search

[Henning Scholland]

Hi Gerd,
so test-map:all-elements did the same as POI-tester? Do you know the
range of the generated POIs? Or is the range based on style?

Henning

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

Re: [mkgmap-dev] GUI for POI Search TYPES

[Henning Scholland]

Hi Gerd,
looks much better now.

I've tried it on my Oregon 600. In some cases in the POI search the
Oregon found a POI, but doesn't display a name. Is there any
explanations for this behavior?

Henning

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

Re: [mkgmap-dev] GUI for POI Search TYPES

[Henning Scholland]

Hi Gerd,
yes it's pretty much the same. Just one problem. Line 0x01-0x08
starting at same position as point 0x7f00-0x7f07. And between lines and
areas the gap is a little bit to big. So I think all the lines should be
shifted a column to the right.

Otherwise: Very good job!

Henning

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

Re: [mkgmap-dev] Roundabouts causes crashing devices

[Henning Scholland]

Hi Minko,

I#m not completly sure, but I remember, there were long time ago 
problems with 2 routable lines on same position. So in my map I changed 
all routeable lines to transparent and used for showing highways etc. 
non-routable lines. But maybe this particular problem was solved later.


Henning

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

Re: [mkgmap-dev] splitter r440 released

[Henning Scholland]

As you know, I'm using overlapping tiles, but in different gmapsupps.
Never had any problems. Is splitter still able to split overlapping tiles?

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

Re: [mkgmap-dev] splitter r440 released

[Henning Scholland]

Should have read your mail better :(

I think the test should be implemented in mkgmap while reading the input
data tiles.

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

Re: [mkgmap-dev] Copyright & License file reader improvements

[Henning Scholland]

Hello,
I think similar. No3 seems to be a very bad idea, as code-page is
different for different maps.

Henning

On 28/12/2016 15:18, Gerd Petermann wrote:
> Hi Mike,
> 
> Mike Baggaley wrote
>> 2:
>> Update the documentation to  indicate that utf-8 must be used for license
>> and copyright file
>> If there is a failure, include the reason for the failure in the exit
>> exception message.
> 
> I have not much experience with this problem, but that would be my favorite.
> 
> What is the current status with the style files? I think they also must be
> in utf-8 nowadays?
> 
> Gerd
> 
> 
> 
> --
> View this message in context: 
> http://gis.19327.n8.nabble.com/Copyright-License-file-reader-improvements-tp5888214p5888257.html
> Sent from the Mkgmap Development mailing list archive at Nabble.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

Re: [mkgmap-dev] Splitter 542 stops working

[Henning Scholland]

Hi Gerd,
thanks a lot for fixing the error. I can confirm v548 is fine agein.

@ Carlos: Yes, I'm always using latest lib-versions

Henning

On 29/12/2016 18:13, Gerd Petermann wrote:
> Hi Henning,
> 
> thanks for reporting. In r548 I  fixed a stupid bug in AreaSet that caused 
> this error.
> I also added a unit test that reproduced the error.
> 
> Gerd
> 
> 
> Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von 
> Henning Scholland <o...@aighes.de>
> Gesendet: Donnerstag, 29. Dezember 2016 10:43:48
> An: Development list for mkgmap
> Betreff: [mkgmap-dev] Splitter 542 stops working
> 
> Hi Gerd,
> yesterday I updated to v542 (v531 same behaviour) of splitter and now
> splitting doesn't work anymore. I'm using an updated planet.o5m with the
> attached areas.list and the following command:
> 
> java -Xmx1M -XX:+UseCompressedOops -XX:+UseParallelGC -jar
> .\bin\splitter.jar --status-freq=0 --output=o5m --max-areas=2048
> --max-threads=%threads% --overlap=0 --keep-complete
> --split-file=.\resources\areas.list --description=RadReiseKarte
> .\data\planet.o5m > splitter.log 2> splitter_error.log
> 
> So far I tested again v476 to check if the o5m-file is still ok. v476 is
> running smooth. Do I need to change anything in my script or wait for
> one of the branches?
> 
> Best regards,
> Henning
> 
> Error:
> java.lang.IndexOutOfBoundsException: Index (14) is greater than or equal
> to list size (14)
> at 
> it.unimi.dsi.fastutil.ints.IntArrayList.removeInt(IntArrayList.java:229)
> at uk.me.parabola.splitter.AreaSet.clear(AreaSet.java:109)
> at uk.me.parabola.splitter.AreaSet.subtract(AreaSet.java:140)
> at
> uk.me.parabola.splitter.MultiTileProcessor.orSubRelWriters(MultiTileProcessor.java:556)
> at
> uk.me.parabola.splitter.MultiTileProcessor.calcWritersOfMultiPolygonRels(MultiTileProcessor.java:436)
> at
> uk.me.parabola.splitter.MultiTileProcessor.endMap(MultiTileProcessor.java:264)
> at
> uk.me.parabola.splitter.AbstractMapProcessor.consume(AbstractMapProcessor.java:73)
> at 
> uk.me.parabola.splitter.OSMFileHandler.execute(OSMFileHandler.java:159)
> at
> uk.me.parabola.splitter.ProblemLists.calcMultiTileElements(ProblemLists.java:250)
> at uk.me.parabola.splitter.Main.useProblemLists(Main.java:474)
> at uk.me.parabola.splitter.Main.start(Main.java:112)
> at uk.me.parabola.splitter.Main.main(Main.java:66)
> ___
> 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] bug?

[Henning Scholland]

Hi,
I could imagine, -H can also be a code for # (Hash-Tag). If eight
matches the regex for 8 I would expect it's changed to 8 and the result
would be H8. As Garmin always capitalizes the first letter of each word,
it seems eight is interpreted as normal word and -H is transformed to #.

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

Re: [mkgmap-dev] r4006: 1st alpha version to write DEM data

[Henning Scholland]

Hi Gerd,
it's a great news. I wanted to try it on my map of China. But
unfortunately failed because of missing files in the sea area between
Korea and Japan. Maybe it's a good 1st approach to interpret a missing
file as an area with 0 elevation.

Anyway, thanks for all the research work on DEM!!!

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

Re: [mkgmap-dev] osmupdate

[Henning Scholland]

You need to update wget to latest version as diffs are only served by https and 
older wget can't use local certificate store. Met the same problem recently...
Henning

⁣Sent from BlueMail ​

On 24 May 2018, 14:01, at 14:01, lig fietser  wrote:
>Since recently I cannot update my osm maps anymore with osmupdate.
>Error: Could not get the newest daily timestamp from the Internet.
>
>
>Anyone familiar with this isssue and how to fix this?
>
>
>
>
>
>
>___
>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] osmupdate

[Henning Scholland]

Maybe you try to download the state. txt manually by wget to get more feedback 
on the cause.
Henning

On 24 May 2018, 22:00, at 22:00, lig fietser <ligfiet...@hotmail.com> wrote:
>Thanks for your hint, I've downloaded the map with full metadata but I
>still get the same error:
>
>Could not get the newest daily timestamp from the Internet.
>
>
>Van: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> namens DD8KQ
><dd...@gmx.de>
>Verzonden: donderdag 24 mei 2018 03:38:19
>Aan: mkgmap-dev@lists.mkgmap.org.uk
>Onderwerp: Re: [mkgmap-dev] osmupdate
>
>
>May be something related to DSVGO, see green banner on top of the
>download site
>
>
>The OpenStreetMap data files provided on this server do not contain the
>user names, user IDs and changeset IDs of the OSM objects. These
>metadata fields contain personal information about the OpenStreetMap
>contributors and are subject to data protection regulations in the
>European Union. Please note that these regulations apply even to
>processing that happens outside the European Union because some
>OpenStreetMap contributors live in the European Union.
>Extracts with full
>metadata<https://osm-internal.download.geofabrik.de/index.html> are
>available to OpenStreetMap contributors only.
>
>Am 24.05.2018 um 11:00 schrieb lig fietser:
>
>Thanks Henning, I updated wget but it still does not work.
>
>My workflow: I have downloaded the europe extract from
>http://download.geofabrik.de
>
>I use osmconvert to cut a section from it (benelux.o5m) and with this
>file I weekly update it with osmupdate.
>
>Until last week this always went well but not anymore.
>
>Any idea how to solve this?
>
>
>
>Van: mkgmap-dev
><mkgmap-dev-boun...@lists.mkgmap.org.uk><mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>
>namens Henning Scholland <o...@hscholland.de><mailto:o...@hscholland.de>
>Verzonden: donderdag 24 mei 2018 00:38:10
>Aan: Development list for mkgmap
>CC: Development list for mkgmap
>Onderwerp: Re: [mkgmap-dev] osmupdate
>
>You need to update wget to latest version as diffs are only served by
>https and older wget can't use local certificate store. Met the same
>problem recently...
>Henning
>
>Sent from BlueMail<http://www.bluemail.me/r?b=13037>
>On 24 May 2018, at 14:01, lig fietser
><ligfiet...@hotmail.com<mailto:ligfiet...@hotmail.com>> wrote:
>
>Since recently I cannot update my osm maps anymore with osmupdate.
>Error: Could not get the newest daily timestamp from the Internet.
>
>
>Anyone familiar with this isssue and how to fix this?
>
>
>
>
>
>mkgmap-dev mailing list
>mkgmap-dev@lists.mkgmap.org.uk<mailto: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<mailto:mkgmap-dev@lists.mkgmap.org.uk>
>http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
>
>--
>
>#
>
> Viele Grüße und 73 de Manfred Haiduk, DD8KQ
>e-mail mhai...@t-online.de<mailto:mhai...@t-online.de>
>dd...@gmx.de<mailto:dd...@gmx.de>
>
>#
>
>
>
>
>___
>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] osmupdate

[Henning Scholland]

Hi
osmupdate is basically a script using wget for downloading and 
osmconvert for merging. As it's using wget in quiet mode, only chance 
for debugging download problems is to download the file manual by wget 
and see the error message. I guess in your case the first file 
(state.txt of daily, hourly or minutely) is failing. So osmupdate can't 
read  which is the latest version of the diffs.


Henning

On 24.05.2018 23:32, lig fietser wrote:


Not sure what you mean with wget Henning. I use osmupdate old.o5m 
new.o5m, not wget and I dont download the whole planet.







Maybe you try to download the state. txt manually by wget to get more 
feedback on the cause.

Henning



___
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] mkgmap r4025 implements --x-dem-poly option

[Henning Scholland]

Hi Gerd,

I got an OutOfMemory exception (see below) while reading zipped 1" SRTM
files in Scandinavia. Unzipped it's all fine.

Btw. it would be nice to move the 'DEM file calculation for ... took 265
ms'-messages from stdout to logging Information.

Henning

Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
    at java.nio.HeapByteBuffer.(Unknown Source)
    at java.nio.ByteBuffer.allocate(Unknown Source)
    at
uk.me.parabola.mkgmap.reader.hgt.HGTReader.extractFromZip(HGTReader.java:123)
    at uk.me.parabola.mkgmap.reader.hgt.HGTReader.(HGTReader.java:90)
    at
uk.me.parabola.mkgmap.reader.hgt.HGTConverter.(HGTConverter.java:66)
    at uk.me.parabola.imgfmt.app.dem.DEMFile.calc(DEMFile.java:47)
    at uk.me.parabola.mkgmap.build.MapBuilder.makeMap(MapBuilder.java:334)
    at
uk.me.parabola.mkgmap.combiners.OverviewBuilder.writeOverviewMap(OverviewBuilder.java:191)
    at
uk.me.parabola.mkgmap.combiners.OverviewBuilder.onFinish(OverviewBuilder.java:103)
    at uk.me.parabola.mkgmap.main.Main.endOptions(Main.java:617)
    at
uk.me.parabola.mkgmap.CommandArgsReader.readArgs(CommandArgsReader.java:128)
    at uk.me.parabola.mkgmap.main.Main.mainStart(Main.java:136)
    at uk.me.parabola.mkgmap.main.Main.main(Main.java:107)

On 28.12.2017 18:18, Gerd Petermann wrote:
> Hi all,
>
> see http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap=4025
> this is useful if you create a map for a country extract like nepal 
> (nepal-latest.osm.pbf)
>
> Here is a screenshot of a map created with the option --x-dem-poly=nepal.poly 
> http://files.mkgmap.org.uk/download/378/nepal-with-poly.jpg
>
> The screenshot also shows some wrong reliefs, and I think I used files 
> without many holes :-(
> So, next step is to find out what goes wrong with DEM in low resolutions. 
> This might take longer, 
> I hope Frank has an idea.
> It seems to be a good idea to use a rather high res for the overview map for 
> now. For the screenshot I used
> --x-overview-dem-dist=276160, with --x-overview-dem-dist=88000 the problems 
> are gone and DEM file is still only
> ~300KB.
>
> Gerd
> P.S.
> See also 
> http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap=%2F=4024
> I've moved some messages into the logger, so there will be less noise from 
> mkgmap.
> ___
> 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] r4033: new dem options are now documented

[Henning Scholland]

Hi Gerd,

do you think using tif (as Frank pointed out even has better compression
ratio) instead of zipped hgt will help regarding the RAM-footprint?

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

Re: [mkgmap-dev] r4015 in dem-tdb branch implements --x-overview-dem-dist

[Henning Scholland]

Hi,
it would be my expected behaviour if you just delete the OSM data and keep the 
area still in your map area.

Henning

⁣Sent from BlueMail ​

On 23 Dec 2017, 10:12, at 10:12, Ervin Malicdem  wrote:
>Hi Gerd,
>
>This is regarding hillshade still being rendered even if the area was
>excluded in the osm file.
>As an example, I specifically removed borneo island in the southwest
>but
>DEM still showed up.
>
>https://www.dropbox.com/s/m6pdz90d3jo1unq/borneo.jpg?dl=0
>
>Ervin M.
>*Schadow1 Expeditions* - A Filipino must not be a stranger to his own
>motherland.
>http://www.s1expeditions.com
>
>On Sat, Dec 23, 2017 at 4:08 PM, Gerd Petermann <
>gpetermann_muenc...@hotmail.com> wrote:
>
>> Hi Ervin,
>>
>> I think there is no longer a need to change splitter since DEM files
>are
>> allowed to grow > 16MB with r4016.
>> Just to make that clear: When I write about DEM files I mean the
>files in
>> the Garmin DEM format, they are either contained in a *.img
>> or in a *.DEM, and they contain the text "GARMIN DEM". I guess DEM
>means
>> something like "Digital Elevation Model".
>> Besides that I don't understand what you mean. Is it about the
>contour
>> lines created by tools like srtm2osm or phyghtmap?
>> What could be improved in splitter?
>>
>> Gerd
>>
>> 
>> Von: ebmalic...@cxsmedia.com  im Auftrag von
>> Ervin Malicdem 
>> Gesendet: Samstag, 23. Dezember 2017 06:21:36
>> An: Development list for mkgmap; gpetermann_muenc...@hotmail.com
>> Betreff: Re: [mkgmap-dev] r4015 in dem-tdb branch implements
>> --x-overview-dem-dist
>>
>> Getting better each time! Great!
>> A suggestion once you will be working with splitter is for the dem to
>be
>> cut using a poly file as well.
>>
>> Ervin M.
>> Schadow1 Expeditions - A Filipino must not be a stranger to his own
>> motherland.
>> http://www.s1expeditions.com
>>
>> On Sat, Dec 23, 2017 at 12:11 AM, Gerd Petermann <
>>
>gpetermann_muenc...@hotmail.com>
>> wrote:
>> Hi,
>>
>> okay, so we now have three new (still undocumented options) to enable
>> hillshading and calculation of elevation data in routes.
>> Here is a summary of the new options:
>>
>> --x-dem=path_to_dir[,path_to_other_dir,...]
>> gives one or more directories containing *.hgt files.
>> --x-dem-dists=n1,n2,n3,...
>> Sample from a Garmin Demo map: --x-dem-dists="5520, 16560, 44176,
>88368"
>> should contain one number for each level in case you want to use the
>DEM
>> data in a gmapsupp, the values give
>> the number of DEM units between two points. A DEM unit is 360° / 2
>^32.
>> The higher the numbers the smaller the DEM file. Useful values for
>level 0
>> start
>> at 1600 if you have 1'' hgt data and a small area, for large areas
>> consider to use 8000 or more. If this option is missing mkgmap will
>> calculate one DEM
>> level based on the resolution of the hgt files.
>> --x-overview-dem-dist=n
>> Use this option to add DEM also to the overview map. The value again
>gives
>> the distance between two DEM points.
>> It the option is not given or the value is 0 the creation of DEM data
>for
>> the overview map is disabled. This might be needed for large areas
>and for
>> overview img files which
>> are already close to 16MB .
>> Useful are probably values > 10, e.g. 256000
>>
>> Expect to see "There is not enough room in a single garmin map for
>all the
>> input data. The .osm file should be split into smaller pieces first."
>> when experimenting with these options. The additional amount of bytes
>for
>> the DEM files depend on the above options, and the relief of the
>area.
>> Mountains
>> require much more space compared to flat areas like the netherlands.
>> If you have contour lines in your overview map try without.
>>
>> I'll try to add code to splitter so that it creates smaller tiles for
>> areas with many mountains. I don't know yet how to store that info.
>>
>> 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

Re: [mkgmap-dev] r4015 in dem-tdb branch implements --x-overview-dem-dist

[Henning Scholland]

Hi Gerd,

after thinking a while about overview-dem and it's not really logical to
me. Mainly the proposed x-overview-dem-dist=0 isn't really intuitive. I
should have thought more better before proposing it. It would be better
to have a separate parameter -x-dem-overview=yes/no, where yes is
default when DEM is activated.

I will try to find a value for overview DEM with my maps. Keep you posted.

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

Re: [mkgmap-dev] Error BeNeLul

[Henning Scholland]

Hi Gerd,
I got a similar error in East Malaysia/Philippine in that tile:
63240328: 188416,5429248 to 538624,5650432

If you need o5m-file let me know.

I used:
x-dem=E:\SRTM\hgt\SRTM3v3.0
x-overview-dem-dist=276160


2nd:
After you changed the file size limit I ran in some of the problematic
tiles into:
SCHWERWIEGEND (BlockManager): .\63240185.o5m: overflowed directory with
max block 65534, current=65535
SCHWERWIEGEND (MapFailedException): .\63240185.o5m: (thrown in
BlockManager.allocate()) Too many blocks. Use a larger block size with
an option such as --block-size=1024 or --block-size=2048
It mainly happen in low data areas in China, Arabia and Australia. I'm
not so sure, if I just should increase the block-size to 128000 or is
there an limit? The examples are quite low values. Can you or someone
else gave me a suggestion?

3rd:
It seems overview-dem is generated for a larger rectangle area, not only
for the existing map area. For areas out of map area (areasa.list,..) I
would expect DEM is treated as 0 elevation.

Henning



On 25.12.2017 17:11, Gerd Petermann wrote:
> Hi Arndt,
>
> I was not able to reproduce this problem. Please tell us your dem options.
>
> Gerd
>
> 
> Von: mkgmap-dev  im Auftrag von Arndt 
> Röhrig 
> Gesendet: Montag, 25. Dezember 2017 03:17:14
> An: Development list for mkgmap
> Betreff: [mkgmap-dev] Error BeNeLul
>
> Happy Christmas :)
>
> i have a problem to build a NRWplus map or a BeNeLux map. (NRW plus all 
> countrys around)
>
> The OSM-Data is reduced to "Bremen". SRTM is NRW & all countrys around.
>
> mkgmap 4000 build a correctly map. mkgmap 4019 crashes with this message:
>
> SCHWERWIEGEND (MapBuilder): ..\Splitter\88039020.osm.pbf: exception while 
> creating DEM file
> SCHWERWIEGEND (MapFailedException): ..\Splitter\88039020.osm.pbf: (thrown in 
> MapBuilder.makeMap()) 23
> SCHWERWIEGEND (MapBuilder): ..\Splitter\88039021.osm.pbf: exception while 
> creating DEM file
> SCHWERWIEGEND (MapFailedException): ..\Splitter\88039021.osm.pbf: (thrown in 
> MapBuilder.makeMap()) 23
>
> gmapsupp will not build with this.
>
> http://www.speichenkarte.de/beta/88039020.osm.pbf
>
>
> Greets
>
> Arndt
> ___
> 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 zipped hgt files

[Henning Scholland]

Hi Gerd,
basically this describes my idea, just less quick ;-) I will give
it a try next weekend.

Of course for every map, you need a individual temp-DEM. So I don't seen
any issues with poly-cutted-tiles.

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

Re: [mkgmap-dev] dem-poly and precomp-sea

[Henning Scholland]

Hi Gerd,
I like the idea to have somehow a map polygone limiting or extending the
'background'-map (means DEM, sea, background poly). How about --map-polygon?

So if I got it right, this develloping will end in non-rectangle shaped
map tiles?
Henning

On 10.01.2018 16:54, Gerd Petermann wrote:
> Hi all,
>
> I think that the bounding polygon given with option --dem-poly should be also 
> be used in the precomp-sea option,
> so that mkgmap doesn't generate sea polygons outside of the bounding polygon. 
> With the current code a map of e.g.
> scandinavia looks strange, see attached picture.
>
> In a further step I should try to use that polygon also for the background 
> polygon (0x4B) and other data.
> In a final step we might be able to use it for routing data so that you can 
> split maps at left-driving / right-driving boundaries,
> but that needs more thinking.
>
> I've not coded anything yet, but I wonder if the option should be changed 
> from dem-poly to e.g. --polygon-file or --bounding-polygon.
>
> 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] --gmapi not in parameter list

[Henning Scholland]

Hi Gerd,
I'm using only --overview-mapname=%famid%. For 'standard'-img map
file name is also set to 1005000.img

Will add also ..number. Thanks for the hint.
Henning

On 11.01.2018 21:06, Gerd Petermann wrote:
> Hi Henning,
>
> I'll add text to the doc and help.
> You you set --overview-mapnumber ?
>
> Gerd
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] --gmapi not in parameter list

[Henning Scholland]

Hi,

is there a reason for not listing --gmapi in the documentation (at least
on website)? Description can be simply:

Outputs map in gmap-format.

Btw: In overview map DEM, LBL, RGN and TRE don't follow map-id based
file name, but using 6234. In my case it should be 1005. NET and
NOD and all map tiles are fine.

Henning

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

Re: [mkgmap-dev] option --show-profiles and DEM

[Henning Scholland]

Hi all,

I don't see a reason to have this option at all. It should be set
automatically to 1 if either contour data or DEM is written. If this
data is in the map, you always want to have it and if those are not in
the map, you don't need it. Or am I wrong?

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

Re: [mkgmap-dev] option --show-profiles and DEM

[Henning Scholland]

Also without show-profiles=1 MapSource and BaseCamp don't use DEM for
elevation of waypoints. Basically it's only used for routing and showing
the shades.

Henning

On 11.01.2018 17:52, lig fietser wrote:
>
> --show-profiles=1
>     Sets a flag in tdb file which enables profile calculation in
> MapSource or
>     Basecamp based on contour lines.
>
>
> No, if show-profiles = 1 and DEM data is present, the profile is
> calculated from the DEM data and *not* from the contour lines
>
>
> If DEM data (see "Hill Shading (DEM) options") is available the flag 
> changes the status line to show the height when you hover over an area
> with  valid DEM data.
>
>
> Agree
>
> Maybe add a remark that if show-profiles = 0 and DEM data is present,
> an elevation profile is always  available?
>
>

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

Re: [mkgmap-dev] DEM-file generation from geo-tiff sources ?

[Henning Scholland]

Hi Frank,
just my opinion:

I would keep this separated from mkgmap. I mean, you need once convert
the data and that's it and the tools all exist. So I think it's more
useful to create a documentation about how to convert the
copernicus-files into hgt.

Btw. Are these files so much better compared to the viewfinder-hgt files?

Henning

On 02.01.2018 22:58, Frank Stinner wrote:
> For my opinion your data sources are very interesting. This is a short
> look to the alps, the tile E40N20 from https://land.copernicus.eu/.
>
> There seem's to be a little problem at the near of some coastlines,
> but we have on the other hand a high resolution of 25m. I belive, a
> bigger problem is the coordinate reference system. Copernicus data
> have EPSG:3035, garmin use EPSG:4326.
>
> It would be fine, if mkgmap could be read geotiffs and calculate with
> different coordinate reference systems. This would perhaps collect the
> interpolation for changing the coordinate reference system and for the
> garmin map. On the other hand: this is a lot of mathematical stuff.
> I'm not a java hacker and i don't know, if there are usable geografic
> librarys for this work.
>
> At the moment we have to translate the tiffs from EPSG:3035 to
> EPSG:4326, then the segmentation in 1°x1° tiffs an at last the
> conversion to hgt files. This should not be a very great problem with
> gdal-tools or so, but it is additional work.
>
>
> Frank
>
>
> ___
> 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] HGT - getElevation()

[Henning Scholland]

On 10.01.2018 20:33, Andrzej Popowski wrote:
> > i would be very defensive with interpolation in the case of
> > missing values.
>
> I got the same feeling. The best way to fill voids is to process whole
> HGT. And I believe that DEM providers already have done it, so any
> attempt at simple extrapolation would rather add errors than make
> output better. In my code I preserve voids. If requested coordinates
> are near void HGT node, then returned value is void.
>
Hi Andrzej,

>From user perspective, I think it's more correct to somehow fill voids
based of surrounding data than using elevation = 0. Elevation=0 I would
only use as a fall back, if whole hgt-file is missing. I agree with you,
that we shouldn't spent a lot of code for guessing.

To have a simple example: If there would be a cone-shape mountain in
reality, but in DEM the top of the cone is missing, I would suggest to
fill the hole with same elevation as the highest circle. So result in
DEM would be a truncated cone shape. Of course reality is not that
simple. :'( ;-)

Henning

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