Re: [mkgmap-dev] Partially not findable street
Hello Steve,
don't panic, everything works fine with your patch.
I had some sparetime and would like to test the display-tool you
recommended below.
But I have trouble to compile it. Is there anywhere a documentation for
compiling this tool? I'm not a java-developer, more C++-beginner.
I have attached the error.log.
Cheers,
Martin
Am 2011-09-26 12:33, schrieb Steve Ratcliffe:
Hi Martin
unfortunately I have deleted all the files, but I have created them
again with the geofabrik-datas from today.
Search for the Engelbertusstraße works:
http://snailrun.de/59.zip
Didn't work:
http://snailrun.de/56789.zip
Thanks very much. I believe I found the problem (or at least a problem).
Could you try out the attached patch please?
In the mdr20 section the streets were being sorted not just by city
name, but also by map number. So it was looking like this:
APPLE STREET
ZOO ROAD
BEE ROAD
ZEBRA ROAD
with Apple and Bee in the same city but different maps, instead of
like this:
APPLE STREET
BEE ROAD
ZEBRA ROAD
ZOO ROAD
I previously suggested that the city being in three tiles rather than
two might have been a problem, but I believe that was not particularly
relevant.
I think that some streets will be un-findable whenever a city falls
across more than one tile.
How can I read the the different mdr-tables?
In the display project (code at http://svn.mkgmap.org.uk/display/trunk)
there are a number of utilities that display various aspects of
the file.
test.display.MdrDisplay
displays the structure of an MDR file
This is reliable since it prints out exactly what is in the file,
but the interpretation of mdr files that are contained within
gmapsup.img files may be incomplete or incorrect.
Pass the name of the file that is or contains an MDR file.
Followed by numbers if you want to limit the sections that are
printed.
test.display.MdrCheck
reads an MDR file and the associated .img files that it was
created from. It cross checks the data between the index and the
img files and prints in a form that shows the meaning rather than
the literal layout of the file.
It can be mis-leading since I just add to it when needed and some
changes I have made to mkgmap are not reflected in this code.
So some of the errors it prints are not errors.
Pass the name of a file (an MDR file, xxx_mdr.img or gmapsupp.img)
Followed by options: --print 5,7 to just print sections 5 and 7
--errors to just print the errors.
..Steve
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Ausgecheckt, Revision 268.
me@Martin:~/App$ cd display/
me@Martin:~/App/display$ ant dist
Buildfile: /home/me/App/display/build.xml
prepare:
[mkdir] Created dir: /home/me/App/display/build/classes
compile:
[javac] /home/me/App/display/build.xml:51: warning: 'includeantruntime' was not set, defaulting to build.sysclasspath=last; set to false for repeatable builds
[javac] Compiling 42 source files to /home/me/App/display/build/classes
[javac] /home/me/App/display/src/test/ExtractFile.java:28: package uk.me.parabola.imgfmt.fs does not exist
[javac] import uk.me.parabola.imgfmt.fs.DirectoryEntry;
[javac]^
[javac] /home/me/App/display/src/test/ExtractFile.java:29: package uk.me.parabola.imgfmt.fs does not exist
[javac] import uk.me.parabola.imgfmt.fs.FileSystem;
[javac]^
[javac] /home/me/App/display/src/test/ExtractFile.java:30: package uk.me.parabola.imgfmt.fs does not exist
[javac] import uk.me.parabola.imgfmt.fs.ImgChannel;
[javac]^
[javac] /home/me/App/display/src/test/ExtractFile.java:31: package uk.me.parabola.imgfmt.sys does not exist
[javac] import uk.me.parabola.imgfmt.sys.ImgFS;
[javac] ^
[javac] /home/me/App/display/src/test/ExtractFile.java:32: package uk.me.parabola.log does not exist
[javac] import uk.me.parabola.log.Logger;
[javac] ^
[javac] /home/me/App/display/src/test/ExtractFile.java:42: cannot find symbol
[javac] symbol : class Logger
[javac] location: class test.ExtractFile
[javac] private static final Logger log = Logger.getLogger(ExtractFile.class);
[javac] ^
[javac] /home/me/App/display/src/test/ExtractFile.java:61: cannot find symbol
[javac] symbol : class FileSystem
[javac] location: class test.ExtractFile
[javac] private void lister(FileSystem fs, ListString filterList) throws IOException {
[javac] ^
[javac] /home/me/App/display/src/test/ExtractFile.java:93: cannot find symbol
[javac] symbol : class ImgChannel
[javac] location: class test.ExtractFile
[javac] private void copyToFile(ImgChannel f, String name) {
[javac]
[mkgmap-dev] Oneway road goes nowhere
Hi ! I use the options --report-dead-ends=2 and have a lot or error warning like this one : Oneway road (http://www.openstreetmap.org/browse/way/116845081) goes nowhere at http://www.openstreetmap.org/?mlat=28.46077mlon=-16.30457zoom=17 The problem is that there are a lot of highway=service, onway=yes that goesto or come from a amenity=parking area. Perhaps mkgmap can check if oneway com/go to parking-areas ? The quick way can also be to make a --report-dead-end=3 , doing the same as =2 but filter highway=service ? If you need more log ... http://dev.openstreetmap.de/aio/mkgmap-errors/ thx for your great work out there ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Perculiar index search concerning bus_stops
It seems that the index search doesn't work correct for POIs which occur very often. Remarks: - Haltestelle (german) = bus stop - Compiler = r2049 Screenshot (BaseCamp OS X) - result OK (many bus_stops available): http://gis.638310.n2.nabble.com/file/n6892353/Haltestellen-OSX.png Screenshot (Dakota 20, FW 4.70) - result NOK (only a few bus_stops available): http://gis.638310.n2.nabble.com/file/n6892353/Haltestellen-Dakota20.bmp Questions: - Has someone observed similar effects? - Has someone an idea concerning the reason? Regards Klaus PS: I have the same effect for power towers. -- View this message in context: http://gis.638310.n2.nabble.com/Perculiar-index-search-concerning-bus-stops-tp6892353p6892353.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
Re: [mkgmap-dev] Perculiar index search concerning bus_stops
POI search has nothing to do with the address index search. Some steps to make sure: 1. Never ever use POI-addresses. That options really crashes loads of things, map does not even have to be activated on device. Enough if one such tile is on the GPS. Sadly many people still using it. 2. Try to see if same effect happens with official garmin maps, or alternatively (not as good) cgpsmapper produced garmin maps -- you need to make sure they use the same 0x code however. Things like power towers have never been included in official garmin maps, so there is no way to checkback. On 14.10.2011 15:02, toc-rox wrote: It seems that the index search doesn't work correct for POIs which occur very often. Remarks: - Haltestelle (german) = bus stop - Compiler = r2049 Screenshot (BaseCamp OS X) - result OK (many bus_stops available): http://gis.638310.n2.nabble.com/file/n6892353/Haltestellen-OSX.png Screenshot (Dakota 20, FW 4.70) - result NOK (only a few bus_stops available): http://gis.638310.n2.nabble.com/file/n6892353/Haltestellen-Dakota20.bmp Questions: - Has someone observed similar effects? - Has someone an idea concerning the reason? Regards Klaus PS: I have the same effect for power towers. -- View this message in context: http://gis.638310.n2.nabble.com/Perculiar-index-search-concerning-bus-stops-tp6892353p6892353.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] [PATCH v1] Using name-tag-list for country names
El 10/10/11 23:42, Carlos Dávila escribió: El 10/10/11 22:43, WanMil escribió: Am 10.10.2011 22:34, schrieb Carlos Dávila: El 10/10/11 21:28, WanMil escribió: El 08/10/11 20:33, WanMil escribió: Up to now the names of the countries were taken from the LocatorConfig.xml file no matter what has been configured in the name-tag-list option. But the name-tag-list option was used to get the country names from the precompiled bounds which causes a problem if country name in the special language is not contained in the LocatorConfig.xml. The patch now uses the name-tag-list consistently for all places where country names are standardized. Additionally the values in the LocatorConfig.xml are automatically completed by all name tags of the precompiled boundaries. http://files.mkgmap.org.uk/detail/37 links to r2047 including this patch. I have tested your patch to build my India map, but get the same errors than without it, plus an new warning from LocatorConfig (see below). Additionally, LocationHook errors with patched mkgmap show names in local languages, despite the use of name-tag-list=int_name,name:en,name Carlos, it seems that mkgmap does not have access to a LocatorConfig.xml. The countries listed in your log are contained in the LocatorConfig.xml provided with mkgmap so they should be found. Did you modify the LocatorConfig.xml file? No, I use the one from trunk. Within the jar file it's placed in the root directory. I extracted it from the jar and is exactly the same that the one in trunk. Looking in other logs I see something is going wrong also with other countries. For example, compiling Spain I get warnings about Algérie and Andorra which are also in LocatorConfig, but not about Spain, Portugal or France. Can you please test it without any modifications to the LocatorConfig? So please remove all LocatorConfig.xml files in your mkgmap environment so that only the one that is provided with the mkgmap build can be used. I did it, compiled with your patched mkgmap and all LocatorConfig warnings went away. Now I have to rebuild my environment to get it working for further tests, but won't have a chance until next Thursday or Friday. Definitely my mkgmap was using an old LocatorConfig.xml instead of current one in trunk. After removing all of them in my mkgmap environment as you suggested all wrong not in locator config messages disappeared from logs. Bye the way: if you want to compile maps for the region India it might be a good idea to fix the boundary of India and Pakistan. They are broken and are not contained in any precompiled boundary. I know it is broken, but I don't want to break out a war in such a hot region by putting the border in the wrong place.;-) Finally I fixed it using boundaries of lower admin_level already existing in OSM, so precompiled boundaries can now include India-Pakistan border. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v1] Using name-tag-list for country names
Can you please test it without any modifications to the LocatorConfig? So please remove all LocatorConfig.xml files in your mkgmap environment so that only the one that is provided with the mkgmap build can be used. I did it, compiled with your patched mkgmap and all LocatorConfig warnings went away. Now I have to rebuild my environment to get it working for further tests, but won't have a chance until next Thursday or Friday. Definitely my mkgmap was using an old LocatorConfig.xml instead of current one in trunk. After removing all of them in my mkgmap environment as you suggested all wrong not in locator config messages disappeared from logs. That's great! I have some additional changes which I will post within the next days before committing them. Bye the way: if you want to compile maps for the region India it might be a good idea to fix the boundary of India and Pakistan. They are broken and are not contained in any precompiled boundary. I know it is broken, but I don't want to break out a war in such a hot region by putting the border in the wrong place.;-) Finally I fixed it using boundaries of lower admin_level already existing in OSM, so precompiled boundaries can now include India-Pakistan border. That's great too! I will precompile the world boundaries within the next days. Is there anyone who likes to fix the south african boundaries? They look awfull because there are several mixed multipolygons for the boundary. WanMil ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v1] Using name-tag-list for country names
Am 14.10.2011 22:15, schrieb WanMil: Is there anyone who likes to fix the south african boundaries? They look awfull because there are several mixed multipolygons for the boundary. I took a look at the boundaries. There are two boundaries with admin_level=2. One containing coastline and the other one containing 12-mile-zone (I guess). If this is causing problems, this should be discussed with local community. In my opinion each country should have just one boundary with admin_level=2. Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v1] Using name-tag-list for country names
Am 14.10.2011 22:15, schrieb WanMil: Is there anyone who likes to fix the south african boundaries? They look awfull because there are several mixed multipolygons for the boundary. Sorry, forget about my first mail. The MP of the boundary contained an error. Should be fixed now. Henning ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Oneway road goes nowhere
On Fri, Oct 14, 2011 at 11:38:47AM +0200, fla...@googlemail.com wrote:
I use the options --report-dead-ends=2 and have a lot or error warning
like this one :
Oneway road (http://www.openstreetmap.org/browse/way/116845081) goes
nowhere at http://www.openstreetmap.org/?mlat=28.46077mlon=-16.30457zoom=17
The problem is that there are a lot of highway=service, onway=yes that
goesto or come from a amenity=parking area.
Perhaps mkgmap can check if oneway com/go to parking-areas ?
Driveways on parking lots can be useful for pedestrian or bicycle routing.
For what it is worth, I have tried to keep finland.osm.pbf clear of these
errors. For parking garages, it is sometimes difficult to guess the parking
aisle layout without local survey. In those cases, I have added fixme=continue
to the parking entrance.
The quick way can also be to make a --report-dead-end=3 , doing the
same as =2 but filter highway=service ?
You can roll your own by doing {add mkgmap:dead-end-check=false}
on highway=service.
Best regards,
Marko
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
