September 2011 - mkgmap-dev - The mkgmap lists

Re: [mkgmap-dev] Error splitting SRTM data
by Michael Prinzing 25 Sep '11

25 Sep '11

On Fri, 23 Sep 2011 09:27:01 +0200, Thorsten Kukuk wrote: >On Fri, Sep 23, Michael Prinzing wrote: > >> On Thu, 22 Sep 2011 16:28:17 +0200, Thorsten Kukuk wrote: >> >> >On Mon, Sep 19, Michael Prinzing wrote: >> > >> >> srtm2osm has a parameter -corrxy to shift the contour lines. Without >> >> this parameters they are not aligned with the real heights. Is >> >> phyghtmap handling this correct? >> > >> >The official version: I cannot see any code adjusting the alignment >> >of the contour lines. For the area where I'm living, it looks >> >perfect even without. >> >> Without correction, contour lines created with srtm2osm are shifted >> about 50m to the south and also about 50m to the west. You will need >> some adequate terrain to see it, but take a look at >> >> http://www.wanderreitkarte.de/index.php?lon=9.8361&lat=48.6375&zoom=17 >> >> There is a gap in the forest to the west. It should match the contour >> lines, but it doesn't. There is a white way with red border that should >> follow the contour lines, but it also doesn't. > >Could it be that the 50m off is a Srtm2Osm bug? Even your >area fits perfect for me. Well, if we assume NASA did align the strm data correctly, there must be something wrong with srtm2osm. The srtm2osm code is old and abandonned, and since I can't compile it at this time, I did not look too deep into it, but I could imagine the following: STRM data is stored in .hgt files, and for everly file the coordinates from the filenames point to the position at which the lower left coner of this file has to be placed. The lower left corner of the whole file is the lower left corner of the lower left pixel in this file, and therefore the /corner/ of this pixel has to be put to the given coordinates. If srtm2osm instead places the /center/ of the lower left pixel to the position given by the coordinates from the filename, this would explain the shift to the south and to the west by half the length of such a pixel. But it's just a guess... Michael

2 1

Enabling routing in map
by Ron Olson 25 Sep '11

25 Sep '11

Hi all- I've been doing some research on maps and mapping and I'm curious how the "routing" feature works in mkgmap insofar as it makes a map routable on a device. I'm trying to learn the underlying algorithms that a device or program might use; clearly there is some sort of additional data being added that makes a map eligible for the routing algorithm to do its job. Thanks for any info!

1 0

Re: [mkgmap-dev] Error splitting SRTM data
by Michael Prinzing 23 Sep '11

23 Sep '11

On Thu, 22 Sep 2011 16:28:17 +0200, Thorsten Kukuk wrote: >On Mon, Sep 19, Michael Prinzing wrote: > >> srtm2osm has a parameter -corrxy to shift the contour lines. Without >> this parameters they are not aligned with the real heights. Is >> phyghtmap handling this correct? > >The official version: I cannot see any code adjusting the alignment >of the contour lines. For the area where I'm living, it looks >perfect even without. Without correction, contour lines created with srtm2osm are shifted about 50m to the south and also about 50m to the west. You will need some adequate terrain to see it, but take a look at http://www.wanderreitkarte.de/index.php?lon=9.8361&lat=48.6375&zoom=17 There is a gap in the forest to the west. It should match the contour lines, but it doesn't. There is a white way with red border that should follow the contour lines, but it also doesn't. >> Since none of the two methods is producing valid data in osm 0.6 >> format, we need a better solution anyway. > >Until now I haven't found any tool which has problems with the >generated 0.6 osm format. The limit of 2000 nodes per way is pretty new, it did not exist in osm 0.5. Since probably nobody will build such a limit intentionally into an existing tool, /today/ there might be few or even no tools really relying on this. But this may change in the future. osmosis for example crashes if I am trying to sort a file containing ways with much more than 2000 nodes. This may have another cause, but it is what I would expect more and more often in the future. >I think "fixing" phyghtmap should be pretty simple. Then I would do it. If there is a limit introduced with a new version of the API, it should be respected wherever possible, IMHO. Michael

2 1

Re: [mkgmap-dev] Splitter insists on the "right" filename when processing pbf data
by Michael Prinzing 22 Sep '11

22 Sep '11

On Tue, 20 Sep 2011 21:58:31 +0100, Steve Ratcliffe wrote: Hello Steve, >> After renaming the file to data.osm.pbf, it works. >> >> Is this intended? Why is the .osm part needed? > >Just because .osm.pbf is the "official" extension name. It can easily be >changed to just .pbf. I can't think of any reason why not, can anyone? Of course, it also would be ok if the splitter would abort with a message like "unknown filename extension". But the message it is currently printing when reading a pbf without .osm part ("only whitespace content allowed before start tag and not \u0 (position: START_DOCUMENT seen \u0...@1:1)") is not really helpful if the only problem is the missing '.osm' in the filename. Michael

1 0

Re: [mkgmap-dev] Error splitting SRTM data
by Michael Prinzing 22 Sep '11

22 Sep '11

On Mon, 19 Sep 2011 18:14:18 +0200, Thorsten Kukuk wrote: >On Mon, Sep 19, Michael Prinzing wrote: >> >> The conversion from osm 0.5 to 0.6 also can be done with osmosis 0.35. >> >> Just call it with >> >> osmosis --read-xml-0.5 enableDateParsing=no file="data_05.osm" --migrate --write-xml file="data_06.osm" >> >> This is adding the missing tags, however it does not split ways containing too many nodes. > >So why should I install additional an old version os osmosis, >if it doesn't do more than what I can do directly by patching >phyghtmap? I don't know much about phyghtmap. If it is an adequate replacement for srtm2osm and if phyton is already present, there probably is no reason to use osmosis. srtm2osm has a parameter -corrxy to shift the contour lines. Without this parameters they are not aligned with the real heights. Is phyghtmap handling this correct? I just suggested osmosis 0.35 because it's a simple alternative for people who are not able or do not want to install phyton or to change the source code. Since none of the two methods is producing valid data in osm 0.6 format, we need a better solution anyway. Michael

2 1

Splitter insists on the "right" filename when processing pbf data
by Michael Prinzing 20 Sep '11

20 Sep '11

Hello, splitting data in pbf format only works if the filename ends with .osm.pbf. When I am trying to split a file named 'data.pbf', the splitter says ------------------------------------------------ Processing data.pbf org.xmlpull.v1.XmlPullParserException: only whitespace content allowed before start tag and not \u0 (position: START_DOCUMENT seen \u0...@1:1) at org.xmlpull.mxp1.MXParser.parseProlog(MXParser.java:1519) at org.xmlpull.mxp1.MXParser.nextImpl(MXParser.java:1395) at org.xmlpull.mxp1.MXParser.next(MXParser.java:1093) atuk.me.parabola.splitter.AbstractXppParser.parse(AbstractXppParser.java :62) at uk.me.parabola.splitter.Main.processMap(Main.java:412) at uk.me.parabola.splitter.Main.calculateAreas(Main.java:287) at uk.me.parabola.splitter.Main.split(Main.java:163) at uk.me.parabola.splitter.Main.start(Main.java:118) at uk.me.parabola.splitter.Main.main(Main.java:107) ------------------------------------------------ After renaming the file to data.osm.pbf, it works. Is this intended? Why is the .osm part needed? Thanks, Michael

2 1

Error while generating the index
by Henning Scholland 20 Sep '11

20 Sep '11

Hi, while generating index with 2023 I got with some maps this error. Has someone an idea what went wrong? It happens with my map of Germany and Denmark, all other maps were ok. Processing of the tiles was fine for all maps. Henning Exception in thread "main" java.lang.NegativeArraySizeException at uk.me.parabola.imgfmt.app.BufferedImgFileReader.get(BufferedImgFileReader.java:165) at uk.me.parabola.imgfmt.app.net.NETFileReader.fetchZipCity(NETFileReader.java:151) at uk.me.parabola.imgfmt.app.net.NETFileReader.getRoads(NETFileReader.java:115) at uk.me.parabola.imgfmt.app.map.MapReader.getRoads(MapReader.java:180) at uk.me.parabola.mkgmap.combiners.MdrBuilder.addStreets(MdrBuilder.java:300) at uk.me.parabola.mkgmap.combiners.MdrBuilder.onMapEnd(MdrBuilder.java:171) at uk.me.parabola.mkgmap.main.Main.endOptions(Main.java:431) at uk.me.parabola.mkgmap.CommandArgsReader.readArgs(CommandArgsReader.java:126) at uk.me.parabola.mkgmap.main.Main.main(Main.java:132)

3 10

Re: [mkgmap-dev] Splitter doesn't process pbf data created with osmosis 0.39
by Michael Prinzing 20 Sep '11

20 Sep '11

On Mon, 19 Sep 2011 17:53:03 +0200, Michael Prinzing wrote: >there seems to be a problem with the latest splitter and data in pbf >format if it was created with osmosis 0.39. After some further testing, it now looks like a problem with osmosis only. If I am converting the pbf data created with osmosis 0.39 back to xml then there also is an empty bounding box that did not exist in the original data and that does not arise if the pbf file was built with osmosis 0.38. I will report this on the mailing list for osmosis. Thank you, Michael

1 0

Name of boundarys
by Thorsten Kukuk 20 Sep '11

20 Sep '11

Hi, currently my maps have only the name of one country for the boundary. I wanted to change that so that the names of both countrys are used and added following rules from the default style: relations: (type=boundary | type=multipolygon) & boundary=administrative & name=* { apply { set mkgmap:boundary_name='$(mkgmap:boundary_name)/${name}' | '${name}'; } } lines: boundary=administrative { name '${mkgmap:boundary_name}' } boundary=administrative & admin_level<3 [0x1e level 5] boundary=administrative & admin_level<5 [0x1d level 4] or alternative in lines: (boundary=administrative & admin_level=2) | boundary=national { name '${mkgmap:boundary_name}' } [0x1e level 5 continue] boundary=administrative & admin_level=4 { name '${mkgmap:boundary_name}' } [0x1d level 4 continue] But for some reasons this rules don't have any affect on the name of the boundarys. I looked at other OSM maps using the same/similar rules, and it looks like they all have the same problem, I don't see it working anywhere. What is wrong with that rules? Similar rules (but without mkgmap:) works fine for other releations like public transport. Thanks, Thorsten -- Thorsten Kukuk, Project Manager/Release Manager SLES SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)

3 8

Re: [mkgmap-dev] Splitter doesn't process pbf data created with osmosis 0.39
by Michael Prinzing 19 Sep '11

19 Sep '11

On Mon, 19 Sep 2011 20:03:20 +0200, Thorsten Kukuk wrote: >On Mon, Sep 19, Michael Prinzing wrote: > >> there seems to be a problem with the latest splitter and data in pbf >> format if it was created with osmosis 0.39. >> >> When I am converting a xml file to pbf by callig osmosis 0.39 just with >> --read-xml and --write pbf parameters, the splitter (called without >> parameters) says: >> >> ------------------------------------------------ >> Processing data_039.osm.pbf >> Bounding box 0.0 0.0 0.0 0.0 >> in 1 file >> Time: Sun Sep 18 15:45:48 CEST 2011 >> Exact map coverage is (0.0,0.0) to (2.1457672119140625E-5,2.1457672119140625E-5) >> Trimmed and rounded map coverage is (0.0,0.0) to (2.1457672119140625E-5,2.1457672119140625E-5) >> Splitting nodes into areas containing a maximum of 1.600.000 nodes each... >> 0 areas: >> ------------------------------------------------ >[...] >> Is this an issue with osmosis 0.39 or with the splitter? > >Works fine for me. Could it be that the bounding box of your >input data is not correct? I don't think so. I've tried with data saved from josm (with the bounding box set correctly) and with other data without a bounding box at all. And the same input data is working if it is converted with osmosis 0.38. I am running the binary distribution of osmosis under Windows XP with Java 1.7. This should not be the problem since it is working with osmosis 0.38, but anyway: what was the environment in which you've tested successfully, and did you compile the source or use the precompiled binary? Michael

3 2