Hi all, it's been a long time since the locator branch was merged and I want to start thinking about what has to be done to merge it back to trunk. So please post your bugs or features that need to be fixed before merging it back to trunk. By the way: do you think the branch should be merged or should we abandon the branch because it has too many flaws? WanMil
Hi WanMil, could you include the pbf-support?! I think this will be a speed improvement. Martin Am 06.06.2011 um 19:33 schrieb WanMil:
Hi all,
it's been a long time since the locator branch was merged and I want to start thinking about what has to be done to merge it back to trunk.
So please post your bugs or features that need to be fixed before merging it back to trunk. By the way: do you think the branch should be merged or should we abandon the branch because it has too many flaws?
WanMil _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Martin, pbf is supported. WanMil
Hi WanMil,
could you include the pbf-support?! I think this will be a speed improvement.
Martin
Am 06.06.2011 um 19:33 schrieb WanMil:
Hi all,
it's been a long time since the locator branch was merged and I want to start thinking about what has to be done to merge it back to trunk.
So please post your bugs or features that need to be fixed before merging it back to trunk. By the way: do you think the branch should be merged or should we abandon the branch because it has too many flaws?
WanMil _______________________________________________ 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
Hi WanMil, which option I've to use with the splitter (splitter-r174) to get a pbf-output? And the mkgmap-locator-r1959 still says: "Error at line 1, col 1 Bad file format: ./test.osm.pbf" Cheers Martin Am 06.06.2011 um 19:46 schrieb WanMil:
Hi Martin,
pbf is supported.
WanMil
Hi WanMil,
could you include the pbf-support?! I think this will be a speed improvement.
Martin
Am 06.06.2011 um 19:33 schrieb WanMil:
Hi all,
it's been a long time since the locator branch was merged and I want to start thinking about what has to be done to merge it back to trunk.
So please post your bugs or features that need to be fixed before merging it back to trunk. By the way: do you think the branch should be merged or should we abandon the branch because it has too many flaws?
WanMil _______________________________________________ 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
Martin, I am talking about mkgmap, not splitter. Francisco Moraes is working on pbf support for splitter and he posted some patches for that. Please search the mkgmap dev list. WanMil
Hi WanMil,
which option I've to use with the splitter (splitter-r174) to get a pbf-output? And the mkgmap-locator-r1959 still says: "Error at line 1, col 1 Bad file format: ./test.osm.pbf"
Cheers Martin
Am 06.06.2011 um 19:46 schrieb WanMil:
Hi Martin,
pbf is supported.
WanMil
Hi WanMil,
could you include the pbf-support?! I think this will be a speed improvement.
Martin
Am 06.06.2011 um 19:33 schrieb WanMil:
Hi all,
it's been a long time since the locator branch was merged and I want to start thinking about what has to be done to merge it back to trunk.
So please post your bugs or features that need to be fixed before merging it back to trunk. By the way: do you think the branch should be merged or should we abandon the branch because it has too many flaws?
WanMil _______________________________________________ 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
WanMil, I know we are talking about mkgmap, but with mkgmap I also get a bad file format error with a pbf-file... Martin Am 06.06.2011 um 20:28 schrieb WanMil:
Martin,
I am talking about mkgmap, not splitter. Francisco Moraes is working on pbf support for splitter and he posted some patches for that. Please search the mkgmap dev list.
WanMil
Hi WanMil,
which option I've to use with the splitter (splitter-r174) to get a pbf-output? And the mkgmap-locator-r1959 still says: "Error at line 1, col 1 Bad file format: ./test.osm.pbf"
Cheers Martin
Am 06.06.2011 um 19:46 schrieb WanMil:
Hi Martin,
pbf is supported.
WanMil
Hi WanMil,
could you include the pbf-support?! I think this will be a speed improvement.
Martin
Am 06.06.2011 um 19:33 schrieb WanMil:
Hi all,
it's been a long time since the locator branch was merged and I want to start thinking about what has to be done to merge it back to trunk.
So please post your bugs or features that need to be fixed before merging it back to trunk. By the way: do you think the branch should be merged or should we abandon the branch because it has too many flaws?
WanMil _______________________________________________ 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
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
How did you create your test.osm.pbf file?
WanMil,
I know we are talking about mkgmap, but with mkgmap I also get a bad file format error with a pbf-file...
Martin
Am 06.06.2011 um 20:28 schrieb WanMil:
Martin,
I am talking about mkgmap, not splitter. Francisco Moraes is working on pbf support for splitter and he posted some patches for that. Please search the mkgmap dev list.
WanMil
Hi WanMil,
which option I've to use with the splitter (splitter-r174) to get a pbf-output? And the mkgmap-locator-r1959 still says: "Error at line 1, col 1 Bad file format: ./test.osm.pbf"
Cheers Martin
Am 06.06.2011 um 19:46 schrieb WanMil:
Hi Martin,
pbf is supported.
WanMil
Hi WanMil,
could you include the pbf-support?! I think this will be a speed improvement.
Martin
Am 06.06.2011 um 19:33 schrieb WanMil:
Hi all,
it's been a long time since the locator branch was merged and I want to start thinking about what has to be done to merge it back to trunk.
So please post your bugs or features that need to be fixed before merging it back to trunk. By the way: do you think the branch should be merged or should we abandon the branch because it has too many flaws?
WanMil _______________________________________________ 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
_______________________________________________ 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
I've used a bounding-box-cut, created with osmosis. Now I've downloaded splitter from trunk, patched with the patch provided by Francisco (19/5/2011, 21:37). Now I can splitt pbf-files to pbf-tiles, but also get: "Error at line 1, col 1 Bad file format: ./tiles_sn/63240345.osm.pbf Error parsing file Error at line 1, col 1 Bad file format: ./tiles_sn/63240346.osm.pbf Error parsing file Error at line 1, col 1 Bad file format: ./tiles_sn/63240347.osm.pbf Error parsing file Error at line 1, col 1 Bad file format: ./tiles_sn/63240348.osm.pbf Error parsing file Error at line 1, col 1 Bad file format: ./tiles_sn/63240349.osm.pbf Error parsing file Error at line 1, col 1 Bad file format: ./tiles_sn/63240350.osm.pbf Error parsing file Exception in thread "main" java.lang.NullPointerException at uk.me.parabola.mkgmap.combiners.FileInfo.getFileInfo(FileInfo.java:139) at uk.me.parabola.mkgmap.main.Main.endOptions(Main.java:428) at uk.me.parabola.mkgmap.CommandArgsReader.readArgs(CommandArgsReader.java:126) at uk.me.parabola.mkgmap.main.Main.main(Main.java:132) " Settings: Splitter: java -Xmx1500M -jar splitter/dist/splitter.jar --mapid=63240345 --max-nodes=1000000 --output-dir=tiles_sn --pbf ./sachsen.osm.pbf Mkgmap: java -Xmx1500M -jar mkgmap-locator-r1959.jar --latin1 --boundsdirectory=bounds --series-name=Germany --family-name=Sachsen --remove-short-arcs --index --net --route --tdbfile --nsis --merge-lines --location-autofill=0 --country-name=Deutschland --country-abbr=DEU --area-name=DEU --family-id=4 --product-id=45 --style-file=./master/basemap_style/ ./tiles_sn/*.osm.pbf ./master/basemap.TYP Cheers Martin Am 06.06.2011 um 20:34 schrieb WanMil:
How did you create your test.osm.pbf file?
WanMil,
I know we are talking about mkgmap, but with mkgmap I also get a bad file format error with a pbf-file...
Martin
Am 06.06.2011 um 20:28 schrieb WanMil:
Martin,
I am talking about mkgmap, not splitter. Francisco Moraes is working on pbf support for splitter and he posted some patches for that. Please search the mkgmap dev list.
WanMil
Hi WanMil,
which option I've to use with the splitter (splitter-r174) to get a pbf-output? And the mkgmap-locator-r1959 still says: "Error at line 1, col 1 Bad file format: ./test.osm.pbf"
Cheers Martin
Am 06.06.2011 um 19:46 schrieb WanMil:
Hi Martin,
pbf is supported.
WanMil
Hi WanMil,
could you include the pbf-support?! I think this will be a speed improvement.
Martin
Am 06.06.2011 um 19:33 schrieb WanMil:
> Hi all, > > it's been a long time since the locator branch was merged and I want to > start thinking about what has to be done to merge it back to trunk. > > So please post your bugs or features that need to be fixed before > merging it back to trunk. > By the way: do you think the branch should be merged or should we > abandon the branch because it has too many flaws? > > WanMil > _______________________________________________ > 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
_______________________________________________ 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
I assume that there is a problem with the splitter pfb creation because the source code of this part should be the same in the locator branch and in the trunk. Can you check that by testing your pbf files with the trunk?
I've used a bounding-box-cut, created with osmosis. Now I've downloaded splitter from trunk, patched with the patch provided by Francisco (19/5/2011, 21:37). Now I can splitt pbf-files to pbf-tiles, but also get:
"Error at line 1, col 1 Bad file format: ./tiles_sn/63240345.osm.pbf Error parsing file Error at line 1, col 1 Bad file format: ./tiles_sn/63240346.osm.pbf Error parsing file Error at line 1, col 1 Bad file format: ./tiles_sn/63240347.osm.pbf Error parsing file Error at line 1, col 1 Bad file format: ./tiles_sn/63240348.osm.pbf Error parsing file Error at line 1, col 1 Bad file format: ./tiles_sn/63240349.osm.pbf Error parsing file Error at line 1, col 1 Bad file format: ./tiles_sn/63240350.osm.pbf Error parsing file Exception in thread "main" java.lang.NullPointerException at uk.me.parabola.mkgmap.combiners.FileInfo.getFileInfo(FileInfo.java:139) at uk.me.parabola.mkgmap.main.Main.endOptions(Main.java:428) at uk.me.parabola.mkgmap.CommandArgsReader.readArgs(CommandArgsReader.java:126) at uk.me.parabola.mkgmap.main.Main.main(Main.java:132) " Settings: Splitter: java -Xmx1500M -jar splitter/dist/splitter.jar --mapid=63240345 --max-nodes=1000000 --output-dir=tiles_sn --pbf ./sachsen.osm.pbf Mkgmap: java -Xmx1500M -jar mkgmap-locator-r1959.jar --latin1 --boundsdirectory=bounds --series-name=Germany --family-name=Sachsen --remove-short-arcs --index --net --route --tdbfile --nsis --merge-lines --location-autofill=0 --country-name=Deutschland --country-abbr=DEU --area-name=DEU --family-id=4 --product-id=45 --style-file=./master/basemap_style/ ./tiles_sn/*.osm.pbf ./master/basemap.TYP
Cheers Martin
Am 06.06.2011 um 20:34 schrieb WanMil:
How did you create your test.osm.pbf file?
WanMil,
I know we are talking about mkgmap, but with mkgmap I also get a bad file format error with a pbf-file...
Martin
Am 06.06.2011 um 20:28 schrieb WanMil:
Martin,
I am talking about mkgmap, not splitter. Francisco Moraes is working on pbf support for splitter and he posted some patches for that. Please search the mkgmap dev list.
WanMil
Hi WanMil,
which option I've to use with the splitter (splitter-r174) to get a pbf-output? And the mkgmap-locator-r1959 still says: "Error at line 1, col 1 Bad file format: ./test.osm.pbf"
Cheers Martin
Am 06.06.2011 um 19:46 schrieb WanMil:
Hi Martin,
pbf is supported.
WanMil
> Hi WanMil, > > could you include the pbf-support?! > I think this will be a speed improvement. > > Martin > > Am 06.06.2011 um 19:33 schrieb WanMil: > >> Hi all, >> >> it's been a long time since the locator branch was merged and I want to >> start thinking about what has to be done to merge it back to trunk. >> >> So please post your bugs or features that need to be fixed before >> merging it back to trunk. >> By the way: do you think the branch should be merged or should we >> abandon the branch because it has too many flaws? >> >> WanMil >> _______________________________________________ >> 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
_______________________________________________ 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
I tried it with the normal branch (http://www.mkgmap.org.uk/snapshots/mkgmap-r1955.tar.gz) and this works for me. Using the trunk (r1961) same error. I hope this information helps you. Cheers Martin Am 06.06.2011 um 21:00 schrieb WanMil:
I assume that there is a problem with the splitter pfb creation because the source code of this part should be the same in the locator branch and in the trunk.
Can you check that by testing your pbf files with the trunk?
I've used a bounding-box-cut, created with osmosis. Now I've downloaded splitter from trunk, patched with the patch provided by Francisco (19/5/2011, 21:37). Now I can splitt pbf-files to pbf-tiles, but also get:
"Error at line 1, col 1 Bad file format: ./tiles_sn/63240345.osm.pbf Error parsing file Error at line 1, col 1 Bad file format: ./tiles_sn/63240346.osm.pbf Error parsing file Error at line 1, col 1 Bad file format: ./tiles_sn/63240347.osm.pbf Error parsing file Error at line 1, col 1 Bad file format: ./tiles_sn/63240348.osm.pbf Error parsing file Error at line 1, col 1 Bad file format: ./tiles_sn/63240349.osm.pbf Error parsing file Error at line 1, col 1 Bad file format: ./tiles_sn/63240350.osm.pbf Error parsing file Exception in thread "main" java.lang.NullPointerException at uk.me.parabola.mkgmap.combiners.FileInfo.getFileInfo(FileInfo.java:139) at uk.me.parabola.mkgmap.main.Main.endOptions(Main.java:428) at uk.me.parabola.mkgmap.CommandArgsReader.readArgs(CommandArgsReader.java:126) at uk.me.parabola.mkgmap.main.Main.main(Main.java:132) " Settings: Splitter: java -Xmx1500M -jar splitter/dist/splitter.jar --mapid=63240345 --max-nodes=1000000 --output-dir=tiles_sn --pbf ./sachsen.osm.pbf Mkgmap: java -Xmx1500M -jar mkgmap-locator-r1959.jar --latin1 --boundsdirectory=bounds --series-name=Germany --family-name=Sachsen --remove-short-arcs --index --net --route --tdbfile --nsis --merge-lines --location-autofill=0 --country-name=Deutschland --country-abbr=DEU --area-name=DEU --family-id=4 --product-id=45 --style-file=./master/basemap_style/ ./tiles_sn/*.osm.pbf ./master/basemap.TYP
Cheers Martin
Am 06.06.2011 um 20:34 schrieb WanMil:
How did you create your test.osm.pbf file?
WanMil,
I know we are talking about mkgmap, but with mkgmap I also get a bad file format error with a pbf-file...
Martin
Am 06.06.2011 um 20:28 schrieb WanMil:
Martin,
I am talking about mkgmap, not splitter. Francisco Moraes is working on pbf support for splitter and he posted some patches for that. Please search the mkgmap dev list.
WanMil
Hi WanMil,
which option I've to use with the splitter (splitter-r174) to get a pbf-output? And the mkgmap-locator-r1959 still says: "Error at line 1, col 1 Bad file format: ./test.osm.pbf"
Cheers Martin
Am 06.06.2011 um 19:46 schrieb WanMil:
> Hi Martin, > > pbf is supported. > > WanMil > >> Hi WanMil, >> >> could you include the pbf-support?! >> I think this will be a speed improvement. >> >> Martin >> >> Am 06.06.2011 um 19:33 schrieb WanMil: >> >>> Hi all, >>> >>> it's been a long time since the locator branch was merged and I want to >>> start thinking about what has to be done to merge it back to trunk. >>> >>> So please post your bugs or features that need to be fixed before >>> merging it back to trunk. >>> By the way: do you think the branch should be merged or should we >>> abandon the branch because it has too many flaws? >>> >>> WanMil >>> _______________________________________________ >>> 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
_______________________________________________ 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
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
On 06/06/11 19:44, Martin wrote:
I've used a bounding-box-cut, created with osmosis. Now I've downloaded splitter from trunk, patched with the patch provided by Francisco (19/5/2011, 21:37). Now I can splitt pbf-files to pbf-tiles, but also get:
"Error at line 1, col 1 Bad file format: ./tiles_sn/63240345.osm.pbf
Whenever you get the error "at line 1, col 1" it is because mkgmap is trying to read the pbf as xml and not as pbf. This is probably because you don't have the required pbf jars in the right place. You can use the same ones as splitter, but you need them in the *same* directory as mkgmap.jar. I now need to do the work so that building mkgmap installs the correct jars out-of-the-box like in splitter. ..Steve
On Mon, Jun 06, 2011 at 08:30:43PM +0200, Martin wrote:
I know we are talking about mkgmap, but with mkgmap I also get a bad file format error with a pbf-file...
For what it is worth, Steve created http://svn.mkgmap.org.uk/splitter/branches/pbf-write for the patch that Francisco Moraes posted and I found some problems with. I did not try out Steve's patch on top of that yet. The splitter --pbf did sort of work for me, but mkgmap complained about missing nodes being referenced by ways (it does not complain about that for XML input), and mkgmap also complained about unclosed polygons that appeared to be closed when going through the XML route. I will try to see what I can do. At least I can silence the warning about missing nodes, or demote it to the INFO level. Marko
Hi WanMil, just a question: How does bnd-file creation work? Does it process everything inside the osm or pbf-file or just relations and ways containing boundary=administrative? If not, this would be a great improvement, because no osmosis is needed. osmosis isn't a very fast tool for filtering data. Another thing would be the generation of a working gmapsupp.img directly with mkgmap. Henning
On Mon, Jun 06, 2011 at 08:16:03PM +0200, Henning Scholland wrote:
Another thing would be the generation of a working gmapsupp.img directly with mkgmap.
+1, that is a show-stopper for me (and presumably others who want to avoid getting involved with proprietary Windows or Mac software). Marko
Hi WanMil,
Henning,
just a question: How does bnd-file creation work? Does it process everything inside the osm or pbf-file or just relations and ways containing boundary=administrative? If not, this would be a great improvement, because no osmosis is needed. osmosis isn't a very fast tool for filtering data.
bnd-file creation processes the whole input file. It does not filter for boundary=administrative. The reason for this is that postal_codes are also accepted. The osmosis step is required because otherwise you probably will have memory problems. If you use unfiltered data for the bnd-creation mkgmap must first read *all* points and *all* ways from the input file. And if you don't have a machine with tons of GB this will exhaust your memory. Maybe someone can do some research if there is a better tool for filtering the boundary data.
Another thing would be the generation of a working gmapsupp.img directly with mkgmap.
Yes, that would be nice but it's not the aim of the locator branch. The locator branch should do a better city/region/country/zip matching but no improvement to the garmin index format.
Henning
WanMil
Hi, there are tools like o5mfilter or osmfilter. They should be faster, but they can't write pbf, just o5m or osm-xml. The Format o5m is much better for filtering data, but there isn't any tool, which converts o5m to pbf. So maybe the the hole process wont be faster. Also o5m is faster then pbf, if you would update your local file with change-sets. I know that this isn't the task of locator-branch, but maybe reading o5m would be one of the next things for bnd-generation and splitter. :-) I will ask in german forum, how to use osmfilter for our filtering and compare it to osmosis. Henning Am 06.06.2011 20:33, schrieb WanMil:
bnd-file creation processes the whole input file. It does not filter for boundary=administrative. The reason for this is that postal_codes are also accepted. The osmosis step is required because otherwise you probably will have memory problems. If you use unfiltered data for the bnd-creation mkgmap must first read *all* points and *all* ways from the input file. And if you don't have a machine with tons of GB this will exhaust your memory. Maybe someone can do some research if there is a better tool for filtering the boundary data.
I have read about the o5m format. It's interesting but at the moment there are some things that need to be solved before supporting o5m. 1. the format definition is not final and not approved by other implementors (only the o5mfilter guy implemented it and there may be some inherent bugs) 2. there is no existing toolchain for o5m (no geofabric dump, no splitter support etc.). mkgmap is the last tool in the chain. 3. the format description contains no hint how non latin characters are stored. All examples use ASCII characters. 4. I don't understand why this new format is faster than pbf. So there should be an independent confirmation about the speed advantages. Unless these points are fixed I don't see any requirements to support o5m. Anyhow it would be interesting if you can post the parameters one has to use to filter the boundaries and postal_codes using o5mfilter (or osmfilter). WanMil
Hi, there are tools like o5mfilter or osmfilter. They should be faster, but they can't write pbf, just o5m or osm-xml. The Format o5m is much better for filtering data, but there isn't any tool, which converts o5m to pbf. So maybe the the hole process wont be faster. Also o5m is faster then pbf, if you would update your local file with change-sets. I know that this isn't the task of locator-branch, but maybe reading o5m would be one of the next things for bnd-generation and splitter. :-)
I will ask in german forum, how to use osmfilter for our filtering and compare it to osmosis.
Henning
Am 06.06.2011 20:33, schrieb WanMil:
bnd-file creation processes the whole input file. It does not filter for boundary=administrative. The reason for this is that postal_codes are also accepted. The osmosis step is required because otherwise you probably will have memory problems. If you use unfiltered data for the bnd-creation mkgmap must first read *all* points and *all* ways from the input file. And if you don't have a machine with tons of GB this will exhaust your memory. Maybe someone can do some research if there is a better tool for filtering the boundary data.
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi, I used osmconvert, o5mfilter and todays germany.osm.pbf from geofabrik (gwdg-mirror). osmconvert.exe germany.osm.pbf --out-o5m >germany.o5m o5mfilter.exe germany.o5m --keep-nodes= --keep-ways-relations="boundary=administrative =postal_code" >grenzen.osm This took just 2 minutes and the result seems to be ok, but I just took a look into data with josm. The size of germany.o5m is about 1.4 GB. Am 06.06.2011 21:12, schrieb WanMil:
Anyhow it would be interesting if you can post the parameters one has to use to filter the boundaries and postal_codes using o5mfilter (or osmfilter).
2 min for germany sounds great! Does the extract contain all ways tagged with boundary=administrative or does it contain only the ways that are referenced in the relations? I also think that osmosis takes too long for this filter job. It's the swiss army knife so you can do everything but other tools are more optimized to specialized tasks. WanMil
Hi, I used osmconvert, o5mfilter and todays germany.osm.pbf from geofabrik (gwdg-mirror).
osmconvert.exe germany.osm.pbf --out-o5m>germany.o5m o5mfilter.exe germany.o5m --keep-nodes= --keep-ways-relations="boundary=administrative =postal_code">grenzen.osm
This took just 2 minutes and the result seems to be ok, but I just took a look into data with josm. The size of germany.o5m is about 1.4 GB.
Am 06.06.2011 21:12, schrieb WanMil:
Anyhow it would be interesting if you can post the parameters one has to use to filter the boundaries and postal_codes using o5mfilter (or osmfilter).
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
WanMil (wmgcnfg@web.de) wrote:
Hi all,
it's been a long time since the locator branch was merged and I want to start thinking about what has to be done to merge it back to trunk.
So please post your bugs or features that need to be fixed before merging it back to trunk. By the way: do you think the branch should be merged or should we abandon the branch because it has too many flaws?
WanMil _______________________________________________ Bear with me, because I haven't tried the locator branch for the reasons I'm about to explain, so my comments may be off the mark...
From my perspective, the locator branch as I understand it will not be much use because the area I live in (in the Middle East) has no useful boundary relations that the locator branch could use. It's not necessarily that people haven't got around to adding this information to the OSM database, but often that this information is not publicly available at all. In the UAE, for instance, there is no formal, systematic address system *whatsoever* (it is completely normal here to give your home location relative to local landmarks such as parks, mosques and malls, rather than giving an address. Makes getting home deliveries a nightmare, but that's another story) so we couldn't add data to the database even if we wanted to. Secondly, the need to pre-process OSM data for boundaries using osmosis strikes me as unwieldy and difficult to maintain. I would much prefer if everything could be self-contained in one executable. Thus, in my opinion any merge back into trunk should still preserve the branch algorithms for retrieving address information. In particular, as Felix said a few weeks ago, I would encourage that address info for POIs is gathered from the addr: tags in those OSM objects (which will encourage people to tag POIs with address info) and the locator algorithms are only: a) offered as an alternative or supplementary option to --location-autofill to get address information for POIs; and b) offered as an option to get address information for streets that are typically never tagged with addr: info. Incidentally, one very quick improvement to the branch handling of addr: tags for POIs would be to fix the bug I pointed out a few weeks ago and the addition of processing of the addr:full tag if that is present as an alternative to individual addr:street, addr:housenumber etc. Just my two fils worth... -- Charlie
available at all. In the UAE, for instance, there is no formal, systematic address system *whatsoever* (it is completely normal here to give your home location relative to local landmarks such as parks, mosques and malls, rather than giving an address. Makes getting home deliveries a nightmare, but that's another story) so we couldn't add data to the database even if we wanted to.
Thanks for delivering some background information. Just out of curiosity: How are the adresses mapped in commercial databases and commercial navigation systems? Are the ususal fields like region, city, street not used in UAE maps? How do you enter an address relative to landmarks into a gpsr?
Johann Gail (johann.gail@gmx.de) wrote:
available at all. In the UAE, for instance, there is no formal, systematic address system *whatsoever* (it is completely normal here to give your home location relative to local landmarks such as parks, mosques and malls, rather than giving an address. Makes getting home deliveries a nightmare, but that's another story) so we couldn't add data to the database even if we wanted to.
Thanks for delivering some background information.
Just out of curiosity: How are the adresses mapped in commercial databases and commercial navigation systems? Are the ususal fields like region, city, street not used in UAE maps? How do you enter an address relative to landmarks into a gpsr?
I have absolutely no idea. But there is no domestic postal service (whether this is a cause, or a consequence, of the lack of addresses I don't know). If you want to receive mail, you receive it to a central PO Box and go to pick it up. When we bought a bed (in person at the shop) we had to draw a map of our location for the delivery man (using major streets and landmarks), because the house we live in has no formal address. In Abu Dhabi (and I suspect also in the other Emirates), a major problem is that most residential streets are just numbered, rather than named, so you have hundreds of 1st Streets, hundreds of 3rd Streets etc (compare http://www.openstreetmap.org/?lat=24.47457&lon=54.37276&zoom=16&layers=M with http://www.openstreetmap.org/?lat=24.45496&lon=54.37316&zoom=17&layers=M - different location, but same street names). There is no postal code to help differentiate them. "Maps" over here are still a novel concept. If a business gives a map, it will quite often be handdrawn, and they sometimes just give you the GPS coordinates directly, see for example the German Vet clinic: http://www.germanvet.ae/contact.html. IKEA recently distributed their new catalogue to all domestic residences and it actually made national news as the sheer logistics of trying to do this when you don't actually know what all the domestic residences are was considered newsworthy! -- Charlie
Hi all,
it's been a long time since the locator branch was merged and I want to start thinking about what has to be done to merge it back to trunk.
So please post your bugs or features that need to be fixed before merging it back to trunk. By the way: do you think the branch should be merged or should we abandon the branch because it has too many flaws?
WanMil _______________________________________________ Bear with me, because I haven't tried the locator branch for the reasons I'm about to explain, so my comments may be off the mark...
From my perspective, the locator branch as I understand it will not be much use because the area I live in (in the Middle East) has no useful boundary relations that the locator branch could use. It's not necessarily that people haven't got around to adding this information to the OSM database, but often that this information is not publicly available at all. In the UAE, for instance, there is no formal, systematic address system *whatsoever* (it is completely normal here to give your home location relative to local landmarks such as parks, mosques and malls, rather than giving an address. Makes getting home deliveries a nightmare, but that's another story) so we couldn't add data to the database even if we wanted to.
Ok, I really wasn't aware of such things...
Secondly, the need to pre-process OSM data for boundaries using osmosis strikes me as unwieldy and difficult to maintain. I would much prefer if everything could be self-contained in one executable.
You've never done that? In case the branch is merged I hope we will be able to provide a download for the precompiled boundaries. So you don't have to do it yourself. By the way: You are using splitter to create tiles? I think that's a quite similar step. The osmosis call is not nice but maybe we get an easier way to filter the boundaries.
Thus, in my opinion any merge back into trunk should still preserve the branch algorithms for retrieving address information. In particular, as Felix said a few weeks ago, I would encourage that address info for POIs is gathered from the addr: tags in those OSM objects (which will encourage people to tag POIs with address info)
Using the locator branch you can use the style file to decide yourself which tags are used to assign the address information. So you can configure to use the addr:* tags.
and the locator algorithms are only: a) offered as an alternative or supplementary option to --location-autofill to get address information for POIs; and
In general: we need an algorithm that helps in regions without boundary information. And maybe some parts of the current location-autofill can be used for this.
b) offered as an option to get address information for streets that are typically never tagged with addr: info.
You can already do this with the style file. But an additional parameter would have some advantages for processing time. So that sounds useful.
Incidentally, one very quick improvement to the branch handling of addr: tags for POIs would be to fix the bug I pointed out a few weeks ago
Can you give me a link to your post? I don't remember...
and the addition of processing of the addr:full tag if that is present as an alternative to individual addr:street, addr:housenumber etc.
I wonder how to achieve that. The garmin format has some address fields like street, zip, city, region, country (and housenumber - but we don't know how to code it?!). All information must be put into these fields. Do you have an idea how to convert addr:full into this schema?
Just my two fils worth...
Thanks for your feedback! WanMil
WanMil (wmgcnfg@web.de) wrote:
Hi all,
it's been a long time since the locator branch was merged and I want to start thinking about what has to be done to merge it back to trunk.
So please post your bugs or features that need to be fixed before merging it back to trunk. By the way: do you think the branch should be merged or should we abandon the branch because it has too many flaws?
WanMil _______________________________________________ Bear with me, because I haven't tried the locator branch for the reasons I'm about to explain, so my comments may be off the mark...
From my perspective, the locator branch as I understand it will not be much use because the area I live in (in the Middle East) has no useful boundary relations that the locator branch could use. It's not necessarily that people haven't got around to adding this information to the OSM database, but often that this information is not publicly available at all. In the UAE, for instance, there is no formal, systematic address system *whatsoever* (it is completely normal here to give your home location relative to local landmarks such as parks, mosques and malls, rather than giving an address. Makes getting home deliveries a nightmare, but that's another story) so we couldn't add data to the database even if we wanted to.
Ok, I really wasn't aware of such things...
Secondly, the need to pre-process OSM data for boundaries using osmosis strikes me as unwieldy and difficult to maintain. I would much prefer if everything could be self-contained in one executable.
You've never done that? In case the branch is merged I hope we will be able to provide a download for the precompiled boundaries. So you don't have to do it yourself. By the way: You are using splitter to create tiles? I think that's a quite similar step. The osmosis call is not nice but maybe we get an easier way to filter the boundaries.
Yes, I agree splitter is an extra step, but on my computer splitter takes 18s to split the whole of the GCC countries (into precisely one tile, natch), whereas from what I've read on the mailing list, osmosis takes much longer to produce the bounds. I understand that if the bounds files are provided for download, that avoids the processing time but unless the bounds are mature (e.g. as they are in Europe), you will have to constantly regenerate it.
Thus, in my opinion any merge back into trunk should still preserve the branch algorithms for retrieving address information. In particular, as Felix said a few weeks ago, I would encourage that address info for POIs is gathered from the addr: tags in those OSM objects (which will encourage people to tag POIs with address info)
Using the locator branch you can use the style file to decide yourself which tags are used to assign the address information. So you can configure to use the addr:* tags.
OK, that's great.
and the locator algorithms are only: a) offered as an alternative or supplementary option to --location-autofill to get address information for POIs; and
In general: we need an algorithm that helps in regions without boundary information. And maybe some parts of the current location-autofill can be used for this. Agreed
b) offered as an option to get address information for streets that are typically never tagged with addr: info.
You can already do this with the style file. But an additional parameter would have some advantages for processing time. So that sounds useful.
Incidentally, one very quick improvement to the branch handling of addr: tags for POIs would be to fix the bug I pointed out a few weeks ago
Can you give me a link to your post? I don't remember...
http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2011q2/011267.html
and the addition of processing of the addr:full tag if that is present as an alternative to individual addr:street, addr:housenumber etc.
I wonder how to achieve that. The garmin format has some address fields like street, zip, city, region, country (and housenumber - but we don't know how to code it?!). All information must be put into these fields. Do you have an idea how to convert addr:full into this schema?
I would suggest that you either parse addr:full (harder, more error prone) and split it down to fields, or just shove it all into addr:housename (if there is no character limit). -- Charlie
Dear Wanmil 1. I would like to see it merged, you've done a great job on it 2. bug 1: please add 'België - Belgique - Belgien' to LocatorConfig.xml 3. bug 2: it's impossible to get the Dutch city of Middelburg in the index. I did a test changing the boundary name to Middleburg which worked great. Somehow Middelburg is not working (up untill version 1961) Johan On Mon, 06 Jun 2011 19:33:45 +0200, WanMil wrote:
Hi all,
it's been a long time since the locator branch was merged and I want to start thinking about what has to be done to merge it back to trunk.
So please post your bugs or features that need to be fixed before merging it back to trunk. By the way: do you think the branch should be merged or should we abandon the branch because it has too many flaws?
WanMil _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Johan,
Dear Wanmil
1. I would like to see it merged, you've done a great job on it Thanks! It's fun.
2. bug 1: please add 'België - Belgique - Belgien' to LocatorConfig.xml I'll do that. I have started to check names worldwide but I can do that for europe next.
3. bug 2: it's impossible to get the Dutch city of Middelburg in the index. I did a test changing the boundary name to Middleburg which worked great. Somehow Middelburg is not working (up untill version 1961)
Hmmm, doesn't sound like that's a special problem of the locator branch. I assume that this is more a problem of sort order in the index creation. Can you give some more details? * Send your areas.list from your splitter * Which splitter parameters do you use? * Which OSM dump do you use (geofabric europe?) * Which mkgmap parameters do you use? WanMil
Johan
On Mon, 06 Jun 2011 19:33:45 +0200, WanMil wrote:
Hi all,
it's been a long time since the locator branch was merged and I want to start thinking about what has to be done to merge it back to trunk.
So please post your bugs or features that need to be fixed before merging it back to trunk. By the way: do you think the branch should be merged or should we abandon the branch because it has too many flaws?
WanMil _______________________________________________ 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
participants (8)
-
charlie＠cferrero.net -
Henning Scholland -
Johann Gail -
Marko Mäkelä -
Martin -
navmaps -
Steve Ratcliffe -
WanMil