Re: [mkgmap-dev] Commit r4270: improve reader for polish (*.mp) format
Hi Gerd, I have tried to compile some more complicated mp. First problem is, that restriction placed on the beginning of the file give multiple warnings, like: SEVERE (RoadNetwork): 8001.mp: 1 can't locate arc from 'via' node 1 to 'to' node 171 on way 431744 SEVERE (RoadNetwork): 8001.mp: 4 can't locate arc from 'via' node 4 to 'to' node 59519 on way 1020461 SEVERE (RoadNetwork): 8001.mp: 8 can't locate arc from 'via' node 8 to 'to' node 80234 on way 812265 Then mkgmap crashes: java.lang.NullPointerException at uk.me.parabola.imgfmt.app.net.RoadNetwork.addRestriction(RoadNetwork.java:320) at uk.me.parabola.mkgmap.general.MapDetails.addRestriction(MapDetails.java:130) at uk.me.parabola.mkgmap.reader.polish.RestrictionHelper.processAndAddRestrictions(RestrictionHelper.java:54) at uk.me.parabola.mkgmap.reader.polish.PolishMapDataSource.load(PolishMapDataSource.java:151) at uk.me.parabola.mkgmap.main.MapMaker.loadFromFile(MapMaker.java:154) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:52) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:289) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:285) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) Exiting - if you want to carry on regardless, use the --keep-going option If I move restriction to the end of file, then there is no warning, but crash is the same: java.lang.NullPointerException at uk.me.parabola.imgfmt.app.net.RoadNetwork.addRestriction(RoadNetwork.java:320) at uk.me.parabola.mkgmap.general.MapDetails.addRestriction(MapDetails.java:130) at uk.me.parabola.mkgmap.reader.polish.RestrictionHelper.processAndAddRestrictions(RestrictionHelper.java:54) at uk.me.parabola.mkgmap.reader.polish.PolishMapDataSource.load(PolishMapDataSource.java:151) at uk.me.parabola.mkgmap.main.MapMaker.loadFromFile(MapMaker.java:154) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:52) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:289) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:285) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) Exiting - if you want to carry on regardless, use the --keep-going option -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit r4270: improve reader for polish (*.mp) format
Hi Gerd, I would rather have mkgmap compatible with real compiler than manual, but in this particular case, both options are reasonable. I'm using the latest version of cGPSmapper 100d. The earliest version I have is 74 from 2004. It behaves the same. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit r4270: improve reader for polish (*.mp) format
Hi Andrzej, thanks for your research. So I think mkgmap should produce the same results as cGPSmapper does? Maybe there are different versions of the binary with different behaviour? I'll have to try what happens without the Endlevel line ... Gerd Von: mkgmap-dev im Auftrag von Andrzej Popowski Gesendet: Samstag, 9. Februar 2019 19:55 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Commit r4270: improve reader for polish (*.mp) format Hi Gerd, I have compiled this example. cGPSmapper doesn't work like in quoted description. When EndLevel is present, cGPSmapper uses only lowest DATA and ignore any other. See description of EndLevel, this one is true: Endlevel=# - The coordinates in the lowest numbered Data# line apply up to the specified EndLevel=#. When compiling example: [RGN40] Type=22 Label= EndLevel=2 Data0=(51.562624,-1.070283),(51.561637,-1.070592),(51.561272,-1.069878), (51.560059,-1.064277) Data1=(51.562624,-1.070283),(51.561272,-1.069878),(51.560059,-1.064277) [END] the result is the same as for: [RGN40] Type=22 Label= EndLevel=2 Data0=(51.562624,-1.070283),(51.561637,-1.070592),(51.561272,-1.069878), (51.560059,-1.064277) [END] You can see the change between level0 and level1, if you remove EndLevel statement: [RGN40] Type=22 Label= Data0=(51.562624,-1.070283),(51.561637,-1.070592),(51.561272,-1.069878), (51.560059,-1.064277) Data1=(51.562624,-1.070283),(51.561272,-1.069878),(51.560059,-1.064277) [END] This means, that GPSMapEdit doesn't display multiple DATA with EndLevel correctly. -- Best regards, Andrzej ___ 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] Commit r4270: improve reader for polish (*.mp) format
Hi Gerd, I have compiled this example. cGPSmapper doesn't work like in quoted description. When EndLevel is present, cGPSmapper uses only lowest DATA and ignore any other. See description of EndLevel, this one is true: Endlevel=# - The coordinates in the lowest numbered Data# line apply up to the specified EndLevel=#. When compiling example: [RGN40] Type=22 Label= EndLevel=2 Data0=(51.562624,-1.070283),(51.561637,-1.070592),(51.561272,-1.069878), (51.560059,-1.064277) Data1=(51.562624,-1.070283),(51.561272,-1.069878),(51.560059,-1.064277) [END] the result is the same as for: [RGN40] Type=22 Label= EndLevel=2 Data0=(51.562624,-1.070283),(51.561637,-1.070592),(51.561272,-1.069878), (51.560059,-1.064277) [END] You can see the change between level0 and level1, if you remove EndLevel statement: [RGN40] Type=22 Label= Data0=(51.562624,-1.070283),(51.561637,-1.070592),(51.561272,-1.069878), (51.560059,-1.064277) Data1=(51.562624,-1.070283),(51.561272,-1.069878),(51.560059,-1.064277) [END] This means, that GPSMapEdit doesn't display multiple DATA with EndLevel correctly. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit r4270: improve reader for polish (*.mp) format
Hi Andrzej, the manual says for that example: "The path is still visible at levels 0 to 3 but the shape changes subtly between level zero (the greatest detail) and level one. At level zero there are four vertices in the line. At levels one and two this reduces to three vertices. What we are actually doing here is specifying that we are only interested in the precise shape of the bend in the path at the highest zoom level. Reducing the detail at higher zoom levels can reduce the size of your digital map, reducing upload times and helping to fit in memory where otherwise it wouldn't. " Gerd Von: mkgmap-dev im Auftrag von Andrzej Popowski Gesendet: Samstag, 9. Februar 2019 12:44 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Commit r4270: improve reader for polish (*.mp) format Hi Gerd, I think GPSMapEdit does it correctly. Each line should be extended up to EndLevel, so it means that first line should be present on levels 0-2 and second on levels 1-2. Multiple DATA in a statement is not a typical case. I think these statements are created usually by GPSMapEdit. I know about to cases. First is, when you truncate map area. This operation can remove a middle part of a polyline and create an object with multiple DATA on the same level. That kind of statement could include EndLevel statement, which should be applied for each DATA. Second case is, when you convert img to mp. In this case, every polyline contains multiple DATA on different levels, but no EndLevel statement. Youd example is a mixed case, but I think EndLevel should be applied for each DATA. -- Best regards, Andrzej ___ 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] Commit r4270: improve reader for polish (*.mp) format
Hi Gerd, I think GPSMapEdit does it correctly. Each line should be extended up to EndLevel, so it means that first line should be present on levels 0-2 and second on levels 1-2. Multiple DATA in a statement is not a typical case. I think these statements are created usually by GPSMapEdit. I know about to cases. First is, when you truncate map area. This operation can remove a middle part of a polyline and create an object with multiple DATA on the same level. That kind of statement could include EndLevel statement, which should be applied for each DATA. Second case is, when you convert img to mp. In this case, every polyline contains multiple DATA on different levels, but no EndLevel statement. Youd example is a mixed case, but I think EndLevel should be applied for each DATA. -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Artifacts in final map (.MP -> .IMG conversion)
Hi Gerd Thanks for options! I'll try them later. About the program used to create .MP There are several programs. As I wrote above, the map is created in the RiffMaster and saved in KMZ format. At the next stage, using a self-writing program, I convert this .KMZ file to .MP. (https://www.rusfishing.ru/forum/threads/konverter-vektornyx-kart-reefmaster-kmz-garmin-img.360704/) -- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Artifacts in final map (.MP -> .IMG conversion)
Hi Gerd! Yes, you can. BUT the source data for creating this file is not collected by me. This data comes with the program ReefMaster (https://reefmaster.com.au). I just created a map in the trial version of this program, saved it in .KMZ and converted it to .MP. Therefore, it is better to ask the author of the program on his forum: https://reefmaster.com.au/index.php/forum/profile/45-matt I am sure that he will not refuse. Just change the copyright field and comments in MP file to the "https://reefmaster.com.au; ЗЫ: By the way, do not forget to make a generalization (in GPSmapEdit) of the source MP-file - this will greatly reduce its size. -- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Artifacts in final map (.MP -> .IMG conversion)
OK, I hope with r4270 most mp files should work now. @Vadim: Can I use your sample file as input for a unit test? Gerd Von: mkgmap-dev im Auftrag von Gerd Petermann Gesendet: Samstag, 9. Februar 2019 08:51 An: Andrzej Popowski; Development list for mkgmap Betreff: Re: [mkgmap-dev] Artifacts in final map (.MP -> .IMG conversion) Hi, please try r4269. I think there is one more problem to solve when data contains data lines for different levels like this example from the manual: [RGN40] Type=22 Label= EndLevel=2 Data0=(51.562624,-1.070283),(51.561637,-1.070592),(51.561272,-1.069878), (51.560059,-1.064277) Data1=(51.562624,-1.070283),(51.561272,-1.069878),(51.560059,-1.064277) [END] Working on it now.. Gerd Von: mkgmap-dev im Auftrag von Andrzej Popowski Gesendet: Freitag, 8. Februar 2019 23:07 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Artifacts in final map (.MP -> .IMG conversion) Hi Gerd, I think I have written about these problems some time ago. There is similar problem for polylines, which contains multiple DATA statement. Each DATA is a separate line in mp format, but mkgmap connects them together, which is wrong: SEVERE (PolishMapDataSource): 29483016.mp: Line null has multiple Data lines - concatenating the points See attached picture with source mp and compiled img in GPSMapEdit. -- Best regards, Andrzej ___ 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] Commit r4270: improve reader for polish (*.mp) format
Version mkgmap-r4270 was committed by gerd on Sat, 09 Feb 2019 improve reader for polish (*.mp) format Fix handling of repeated DATA lines with different levels Sample from manual: [RGN40] Type=22 Label= EndLevel=2 Data0=(51.562624,-1.070283),(51.561637,-1.070592),(51.561272,-1.069878), (51.560059,-1.064277) Data1=(51.562624,-1.070283),(51.561272,-1.069878),(51.560059,-1.064277) [END] Note that GpsMapEdit doesn't seem to understand that as it adds two lines, one for level 0-2, another for levels 1-2 while there should be one at level 0 and another at 1-2 http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap=4270 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Shouldn't both options --gmapi and --nsis imply --tdbfile?
Hello I was a newbie two years ago or so.. It took me a lot and a lot of time to fall in all the gaps and holes and try to understand. I,m still reading the options manual trying to find out what polygon-size-limits really mean. The internet does help but I think only for techies knowing what all the words mean in the first place. I first started with mapuploader but also that one tries to expose all the options to the user making it very difficult. As soon as you find out where all the options are good for you also don;t need the interface anymore For that reason I created an excel sheet user interface with some one trick buttons creating cmd scripts to be executed. I'm not fan of the VBA excel as a generic distributable thing, don't worry, but the concept is clear: Download geofabrik region sea and bounds if not already exists and kick the map with default style which ends up with mymap-setup.exe and gmapsupp.img and runs the silent installer immediately. To keep the cmd-scripts of the older generation intact for backword compatibility, maybe these are some options: mkgmap-simple.jar --http://geofabrik/europe/luxembourg-latest.osm.pbf or mkgmap.jar --default --http://geofabrik/europe/luxembourg-latest.osm.pbf or mkgmap.cmd or mkgmap.ps1 doing the same (one for linux, mac and windows) Maybe this can help newbies Gr Joris -Oorspronkelijk bericht- Van: mkgmap-dev Namens Gerd Petermann Verzonden: dinsdag 5 februari 2019 10:13 Aan: Development list for mkgmap Onderwerp: Re: [mkgmap-dev] Shouldn't both options --gmapi and --nsis imply --tdbfile? Hi all, I still don't dare to change the option handling in mkgmap completely. My understanding is that we have two groups of users: - One large group uses mkgmap since long and has all kinds of scripts which expect exactly the current behaviour. Thus I consider backward compatibility very important. - One small group (the newbies) try to create a map on their own and those are lost with all the options needed to get a good map. I think those users would also not profit if we suddenly change all kinds of defaults because they will find even more confusing hints and howtos. Maybe there is someone who volunteers to create a small beginners guide? A very simple one woud be this: Recommended options to create a map for car routing with full address search: --gmapi --gmapsupp --nsis --index --split-name-index --bounds=bounds.zip --housenumbers --route --check-roundabouts --add-pois-to-areas --link-pois-to-ways --process-destination --process-exits Just reading Tickers comment it seems that we created almost the same list here, but I would not recommend to use --remove-ovm-work-files. In fact I thought about removing this option as it is likely to cause trouble when you try to compile the map in multiple steps. The default for --add-boundary-nodes-at-admin-boundaries is (and was) 2 since the merge into trunk. Gerd Von: mkgmap-dev im Auftrag von Ticker Berkin Gesendet: Dienstag, 5. Februar 2019 09:54 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Shouldn't both options --gmapi and --nsis imply --tdbfile? Hi I think it is reasonable that mkgmap, when explicitly being used to generate GMAPSUPP.IMG doesn't generate PC files unless other options imply that a PC image is also wanted - it does take extra time and a lot of memory. Options --gmapi or --tdbfile imply PC files are wanted and should cause generation of PC indexes if --index is on. My thoughts on the default values of options: When new features are introduced, they should be OFF by default - experts who follow the development can turn them on if they want to experiment. A while later, when the feature has settled down and is thought to be generally good, the default should be changed to ON. Some candidates for now being ON by default --gmapsupp --index --location-autofill=is_in,nearest --route --add-pois-to-area --link-pois-to-ways --process-exits --process-destination --remove-ovm-work-files maybe also --check_roundabout*, but I'm not sure of the default values for these and the help text doesn't say About now would be the time for changing: --add-boundary-nodes-at-admin-boundaries= from 0 to 2 Regards Ticker On Mon, 2019-02-04 at 18:12 -0500, EthnicFood IsGreat wrote: > > > > Message: 1 > > Date: Sun, 03 Feb 2019 09:15:33 -0500 > > From: Greg Troxel > > To: Gerd Petermann > > Cc: "mkgmap-dev@lists.mkgmap.org.uk" < > > mkgmap-dev@lists.mkgmap.org.uk> > > Subject: Re: [mkgmap-dev] Shouldn't both options --gmapi and --nsis > > imply --tdbfile? > > > > > > Gerd Petermann writes: > > > > > I never understood why adding option --gmapsupp suppresses the > > > creation of the pc index file(s). Is it really only because the > > > current implementation requires more memory? > > I don't understand either, and it feels like a bug. > > > > I have long been in favor of
