Re: [mkgmap-dev] Eclipse
Hello, I’m using Eclipse Luna Service Release 1 (4.4.1) Build id: 20140925-1800 on OS X 10.10. I don’t think my changes make any difference to where you keep your working directory or source, or how you organize your workspace. What specific part of the patch do you think would break your eclipse setup? Can you apply the patch and identify any issues? I don’t have splitter checked out, so I added any ivy dependency to download it. If you have splitter in your workspace you can give that priority over ivy. Brian > On Oct 23, 2014, at 3:22 PM, WanMil wrote: > > Hi Brian, hi Gerd, > > just my two cents: > > I use Eclipse in the following way: > I use one workspace (e.g. c:\workspace). > I'll checkout the projects to this workspace named mkgmap_trunk, > splitter_trunk etc. After checking out I run the ant target "resolve" within > eclipse. After that the workspace is completely ready. > > When I want to implement a new feature or I want to try an older revision I > checkout mkgmap into another directory below c:\workspace and run the ant > script with "resolve". > > In my mkgmap start scripts I define the directory below the workspace, e.g. > MKGMAP_DIR=c:\workspace\mkgmap and use this variable in the startup call. > It would also be possible to run ant dist first and define the dist directory > in the workspace as mkgmap directory. > > This makes it easy to switch between different versions and development > variants. > > WanMil > > >> Hi Brian, >> >> thanks for the patch. >> >> I agree that you can't use the current source in eclipse without manual >> work. >> When I started with mkgmap and splitter I also started using eclipse >> (and coding in Java), so >> I did more or less the same you did, but I did not dare to say that my >> solution is "correct", probably it is far away from being a good solution. >> >> I am not sure if my environment will continue to work with your patch. >> >> 1) My current environment looks like this: >> - I am using Eclipse "Version: Juno Service Release 2 Build id: >> 20130225-0426" on a Windows 7 64 bit machine >> - I have one directory called d:\eclipse_workspace containing sub >> directories mkgmap, splitter, display and others >> for each project >> - the source directories are located in d:\mkgmap or d:\splitter >> >> 2) When I try to reproduce problems in older mkgmap releases I close >> Eclipse, rename e.g. d:\mkgmp to d:\mkgmap_trunk >> and do a svn checkout of the wanted sources to d:\mkgmap. Next I use ant >> dist to build. >> After that I start Eclipse and do a refresh for the whole mkgmap >> project, maybe also a clean. >> Sometimes I have to repeat the ant dist and refresh to be able to debug >> mkgmap in Eclipse. >> >> Depending on the release of mkgmap that I am compiling I have to modify >> the names of libraries. >> >> If I got it right, you suggest to use the source directory (e.g. >> d:\mkgmap in my case) also as working directory for Eclipse? >> >> Gerd >> >> >> From: briane...@gmail.com >> Date: Wed, 22 Oct 2014 23:30:18 -0400 >> To: mkgmap-dev@lists.mkgmap.org.uk >> Subject: [mkgmap-dev] Eclipse >> >> Hello, >> >> I’ve recently downloaded the mkgmap source. I had no trouble compiling >> it with ant, but getting Eclipse to work took some effort. I’ve attached >> a patch file containing changes for Eclipse. >> >> The specific changes are: >> * update classpath to find current version of jars >> * add ivyde settings >> * add Eclipse setting file to specify source=1.7 >> * add splitter to ivy to compile ‘optional’ bit >> * update URL of opengeo ivy repository >> * add bin/tmp to ignore list >> >> I see there is a git copy of this project, but it appears all commits >> are going through svn. I’d prefer to create a pull request on github >> than to attach a patch file, but am happy to do whatever works. >> >> Attached is the patch file for review and merging to >> http://svn.mkgmap.org.uk/mkgmap/trunk. >> >> >> >> Regards, >> Brian >> >> ___ 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
Re: [mkgmap-dev] Eclipse
Hi Brian, hi Gerd, just my two cents: I use Eclipse in the following way: I use one workspace (e.g. c:\workspace). I'll checkout the projects to this workspace named mkgmap_trunk, splitter_trunk etc. After checking out I run the ant target "resolve" within eclipse. After that the workspace is completely ready. When I want to implement a new feature or I want to try an older revision I checkout mkgmap into another directory below c:\workspace and run the ant script with "resolve". In my mkgmap start scripts I define the directory below the workspace, e.g. MKGMAP_DIR=c:\workspace\mkgmap and use this variable in the startup call. It would also be possible to run ant dist first and define the dist directory in the workspace as mkgmap directory. This makes it easy to switch between different versions and development variants. WanMil Hi Brian, thanks for the patch. I agree that you can't use the current source in eclipse without manual work. When I started with mkgmap and splitter I also started using eclipse (and coding in Java), so I did more or less the same you did, but I did not dare to say that my solution is "correct", probably it is far away from being a good solution. I am not sure if my environment will continue to work with your patch. 1) My current environment looks like this: - I am using Eclipse "Version: Juno Service Release 2 Build id: 20130225-0426" on a Windows 7 64 bit machine - I have one directory called d:\eclipse_workspace containing sub directories mkgmap, splitter, display and others for each project - the source directories are located in d:\mkgmap or d:\splitter 2) When I try to reproduce problems in older mkgmap releases I close Eclipse, rename e.g. d:\mkgmp to d:\mkgmap_trunk and do a svn checkout of the wanted sources to d:\mkgmap. Next I use ant dist to build. After that I start Eclipse and do a refresh for the whole mkgmap project, maybe also a clean. Sometimes I have to repeat the ant dist and refresh to be able to debug mkgmap in Eclipse. Depending on the release of mkgmap that I am compiling I have to modify the names of libraries. If I got it right, you suggest to use the source directory (e.g. d:\mkgmap in my case) also as working directory for Eclipse? Gerd From: briane...@gmail.com Date: Wed, 22 Oct 2014 23:30:18 -0400 To: mkgmap-dev@lists.mkgmap.org.uk Subject: [mkgmap-dev] Eclipse Hello, I’ve recently downloaded the mkgmap source. I had no trouble compiling it with ant, but getting Eclipse to work took some effort. I’ve attached a patch file containing changes for Eclipse. The specific changes are: * update classpath to find current version of jars * add ivyde settings * add Eclipse setting file to specify source=1.7 * add splitter to ivy to compile ‘optional’ bit * update URL of opengeo ivy repository * add bin/tmp to ignore list I see there is a git copy of this project, but it appears all commits are going through svn. I’d prefer to create a pull request on github than to attach a patch file, but am happy to do whatever works. Attached is the patch file for review and merging to http://svn.mkgmap.org.uk/mkgmap/trunk. Regards, Brian ___ 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] Error on barrier
Am 23.10.2014 13:49, schrieb Stéphane MARTIN: > Compiling the map for France, I get this error (twice) : > > GRAVE (StyledConverter): 6237.o5m: Found multiple points with equal > coords as CoordPOI at > http://www.openstreetmap.org/?mlat=43.859890&mlon=4.441025&zoom=17 > > - mkgmap-r3337 > - splitter-r412 > > Do you think the problem is in my style files ? No, error in OSM Data. 2 Nodes with same coordinates. I just fixed this. Chris ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Error on barrier
Hi, Compiling the map for France, I get this error (twice) : GRAVE (StyledConverter): 6237.o5m: Found multiple points with equal coords as CoordPOI at http://www.openstreetmap.org/?mlat=43.859890&mlon=4.441025&zoom=17 - mkgmap-r3337 - splitter-r412 Do you think the problem is in my style files ? Regards. Steph ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Eclipse
Hi Brian, thanks for the patch. I agree that you can't use the current source in eclipse without manual work. When I started with mkgmap and splitter I also started using eclipse (and coding in Java), so I did more or less the same you did, but I did not dare to say that my solution is "correct", probably it is far away from being a good solution. I am not sure if my environment will continue to work with your patch. 1) My current environment looks like this: - I am using Eclipse "Version: Juno Service Release 2 Build id: 20130225-0426" on a Windows 7 64 bit machine - I have one directory called d:\eclipse_workspace containing sub directories mkgmap, splitter, display and others for each project - the source directories are located in d:\mkgmap or d:\splitter 2) When I try to reproduce problems in older mkgmap releases I close Eclipse, rename e.g. d:\mkgmp to d:\mkgmap_trunk and do a svn checkout of the wanted sources to d:\mkgmap. Next I use ant dist to build. After that I start Eclipse and do a refresh for the whole mkgmap project, maybe also a clean. Sometimes I have to repeat the ant dist and refresh to be able to debug mkgmap in Eclipse. Depending on the release of mkgmap that I am compiling I have to modify the names of libraries. If I got it right, you suggest to use the source directory (e.g. d:\mkgmap in my case) also as working directory for Eclipse? Gerd From: briane...@gmail.com Date: Wed, 22 Oct 2014 23:30:18 -0400 To: mkgmap-dev@lists.mkgmap.org.uk Subject: [mkgmap-dev] Eclipse Hello, I’ve recently downloaded the mkgmap source. I had no trouble compiling it with ant, but getting Eclipse to work took some effort. I’ve attached a patch file containing changes for Eclipse. The specific changes are:* update classpath to find current version of jars* add ivyde settings* add Eclipse setting file to specify source=1.7* add splitter to ivy to compile ‘optional’ bit* update URL of opengeo ivy repository* add bin/tmp to ignore list I see there is a git copy of this project, but it appears all commits are going through svn. I’d prefer to create a pull request on github than to attach a patch file, but am happy to do whatever works. Attached is the patch file for review and merging to http://svn.mkgmap.org.uk/mkgmap/trunk. Regards,Brian ___ 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] Rendering Tunnels
Hi programmers, attached is a patch. The problem: mkgmap r3337 doesn't check if a "road" is rendered at level 0. Because of this missing check it adds the road to the NOD file but doesn't write it at level 0, which causes broken routing. I don't know if this is an old error, at least I did not find a change that introduced it. The problem is partly caused by the way how we process rules. Up to now mkgmap sets an internal "road" flag when it finds the road_speed or road_class attributes within the square brakets. Later it processes the resolution/level information. Again later it processes the level statement to find out which resolution is placed in what level. When this is done it is clear whether a given resolution appears at level 0 which is the only one that is routabable. On the other hand, some routines simply check the "road" flag to determine if a line is a routable way or not using the GType.isRoad() method. I changed the meaning of isRoad() and added a method hasRoadAttribute() which can be used when the old meaning is needed. Maybe isRoad() should also verify the result of isRoutableLineType() ? Gerd Date: Wed, 22 Oct 2014 21:43:51 +0200 From: elib...@gmail.com To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Rendering Tunnels Gerd thanks for the comment - it's likely a bug in facs: I tried again with same result, # WORKING OK enrico@gling:/opt/osm/test$ ls -l gmapsupp.img -rw-rw-r-- 1 enrico enrico 87724032 ott 22 00:15 gmapsupp.img #copied lines style file to lines_last adding "road_class=2 road_speed=3" enrico@gling:/opt/osm/mystyle/r2946/default$ diff lines lines_last 172c172 < highway=secondary [0x04 road_class=2 road_speed=3 resolution 20-21 continue] --- > highway=secondary [0x04 resolution 20-21 continue] # ROUTING IS BROKEN enrico@gling:/opt/osm/test$ ls -l gmapsupp.img -rw-rw-r-- 1 enrico enrico 88676352 ott 22 21:30 gmapsupp.img note that the latter gmapsupp.img with broken routing is 1MB larger than the working one, so it has clearly something more in it while it should not if the routing graph is just the result of res 24 ways... On Wed, Oct 22, 2014 at 8:37 AM, Gerd Petermann wrote: Hi Enrico, I think this change should NOT have an influence on routing, so it would be an error in mkgmap if it does. Please double check this result. Gerd Date: Tue, 21 Oct 2014 23:33:31 +0200 From: elib...@gmail.com To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Rendering Tunnels Dzięki Andrzej! By removing "road_class=2 road_speed=3" from the 2nd line, routing works and tunnels are visible - here is how it looks line: highway=secondary & ( network=e-road | int_ref=* ) [0x04 resolution 18-19 continue] highway=secondary [0x04 resolution 20-21 continue] highway=secondary & tunnel=yes [0x11 road_class=2 road_speed=3 resolution 22] highway=secondary [0x04 road_class=2 road_speed=3 resolution 22] All looks fine now, and routable! Enrico On Tue, Oct 21, 2014 at 3:30 PM, Andrzej Popowski wrote: Hi Enrico, > I believe this was my intention: up to res 21 I'd like the line to > appear as 0x04, from resolution 22 it should appear as 0x11 if a > tunnel, otherwise 0x04 - no further processing is needed. Could you > pls let me know why the reasoning is not correct? This is correct. I have assumed that you'd like to get 2 lines for tunnels: standard road and additional marking for tunnel. As I understand, routing parameters are only valid for layer 24 (or the last layer in a map). I would remove road_class and road_speed from line: highway=secondary [0x04 road_class=2 road_speed=3 resolution 20-21 continue] Maybe this is the reason for routing errors? -- 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 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 isroad-v1.patch Description: Binary data ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] gmappsupp size with 20% bigger when using latest splitter
ops - you must be right! thanks On Thu, Oct 23, 2014 at 8:29 AM, Gerd Petermann < gpetermann_muenc...@hotmail.com> wrote: > Hi Enrico, > > splitter r412 should produce fewer tiles, so one explanation might be that > the last for > tiles were not produced by r412. Since your listing shows different > timestamps for them > I'd say you did not start with a clean directory. > > Gerd > > -- > Date: Thu, 23 Oct 2014 00:03:15 +0200 > From: elib...@gmail.com > To: mkgmap-dev@lists.mkgmap.org.uk > Subject: [mkgmap-dev] gmappsupp size with 20% bigger when using latest > splitter > > > I updated my splitter version from 314 to 412 - now, it's pretty late but > I read about the new split algorithm that might cause some different sizes > than before, maybe I searched too quickly but I can't seem to explain why > the final gmapsupp went from 87MB to 107MB. > > Looking at the split output in 412 and 314, it's clear 412 creates bigger > files. Strange enough the last 4 files have the same size... > > # splitter 412 > 10637241 oct 22 23:23 7061.osm.pbf > 12379309 oct 22 23:23 7062.osm.pbf > 12233125 oct 22 23:23 7063.osm.pbf > 12607475 oct 22 23:23 7064.osm.pbf > 14031652 oct 22 23:23 7065.osm.pbf > 12025643 oct 22 23:23 7066.osm.pbf > 9286836 oct 22 23:23 7067.osm.pbf > 11071432 oct 22 23:23 7068.osm.pbf > 11720495 oct 22 23:23 7069.osm.pbf > 11909440 oct 22 23:23 70600010.osm.pbf > 12356777 oct 22 23:23 70600011.osm.pbf > 11513810 oct 22 23:23 70600012.osm.pbf > 11672847 oct 22 23:23 70600013.osm.pbf > 11988497 oct 22 23:23 70600014.osm.pbf > > > > * 9209424 oct 22 22:28 70600015.osm.pbf 11793063 oct 22 22:28 > 70600016.osm.pbf 10161776 oct 22 22:28 70600017.osm.pbf 10080071 oct 22 > 22:28 70600018.osm.pbf* > > # splitter 314 > 7323072 oct 22 23:43 7061.osm.pbf > 8832797 oct 22 23:43 7062.osm.pbf > 9987720 oct 22 23:43 7063.osm.pbf > 8862868 oct 22 23:43 7064.osm.pbf > 7198648 oct 22 23:43 7065.osm.pbf > 9651244 oct 22 23:43 7066.osm.pbf > 10898020 oct 22 23:43 7067.osm.pbf > 9764169 oct 22 23:43 7068.osm.pbf > 8247811 oct 22 23:43 7069.osm.pbf > 9444801 oct 22 23:43 70600010.osm.pbf > 8876247 oct 22 23:43 70600011.osm.pbf > 9218641 oct 22 23:43 70600012.osm.pbf > 7222814 oct 22 23:43 70600013.osm.pbf > 9883513 oct 22 23:43 70600014.osm.pbf > > > > * 9209424 oct 22 23:43 70600015.osm.pbf 11793063 oct 22 23:43 > 70600016.osm.pbf 10161776 oct 22 23:43 70600017.osm.pbf 10080071 oct 22 > 23:43 70600018.osm.pbf* > > Does this sound right to you? > > Thanks! > Enrico > > > ___ 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] Rendering Tunnels
Hi Enrico, thanks for the info, I really seems that mkgmap writes invalid data in the case that doesn't work. I'll try to find out why... Gerd Date: Wed, 22 Oct 2014 21:43:51 +0200 From: elib...@gmail.com To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Rendering Tunnels Gerd thanks for the comment - it's likely a bug in facs: I tried again with same result, # WORKING OK enrico@gling:/opt/osm/test$ ls -l gmapsupp.img -rw-rw-r-- 1 enrico enrico 87724032 ott 22 00:15 gmapsupp.img #copied lines style file to lines_last adding "road_class=2 road_speed=3" enrico@gling:/opt/osm/mystyle/r2946/default$ diff lines lines_last 172c172 < highway=secondary [0x04 road_class=2 road_speed=3 resolution 20-21 continue] --- > highway=secondary [0x04 resolution 20-21 continue] # ROUTING IS BROKEN enrico@gling:/opt/osm/test$ ls -l gmapsupp.img -rw-rw-r-- 1 enrico enrico 88676352 ott 22 21:30 gmapsupp.img note that the latter gmapsupp.img with broken routing is 1MB larger than the working one, so it has clearly something more in it while it should not if the routing graph is just the result of res 24 ways... On Wed, Oct 22, 2014 at 8:37 AM, Gerd Petermann wrote: Hi Enrico, I think this change should NOT have an influence on routing, so it would be an error in mkgmap if it does. Please double check this result. Gerd Date: Tue, 21 Oct 2014 23:33:31 +0200 From: elib...@gmail.com To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Rendering Tunnels Dzięki Andrzej! By removing "road_class=2 road_speed=3" from the 2nd line, routing works and tunnels are visible - here is how it looks line: highway=secondary & ( network=e-road | int_ref=* ) [0x04 resolution 18-19 continue] highway=secondary [0x04 resolution 20-21 continue] highway=secondary & tunnel=yes [0x11 road_class=2 road_speed=3 resolution 22] highway=secondary [0x04 road_class=2 road_speed=3 resolution 22] All looks fine now, and routable! Enrico On Tue, Oct 21, 2014 at 3:30 PM, Andrzej Popowski wrote: Hi Enrico, > I believe this was my intention: up to res 21 I'd like the line to > appear as 0x04, from resolution 22 it should appear as 0x11 if a > tunnel, otherwise 0x04 - no further processing is needed. Could you > pls let me know why the reasoning is not correct? This is correct. I have assumed that you'd like to get 2 lines for tunnels: standard road and additional marking for tunnel. As I understand, routing parameters are only valid for layer 24 (or the last layer in a map). I would remove road_class and road_speed from line: highway=secondary [0x04 road_class=2 road_speed=3 resolution 20-21 continue] Maybe this is the reason for routing errors? -- 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 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
