Re: [mkgmap-dev] Global index branch
On Sat, Feb 26, 2011 at 11:30:50PM +0100, Carlos Dávila wrote: I know max-nodes is quite too high, but after removing CORINE data with osmosis there's a lot of unused nodes. Side note: Have you considered adding --used-node to the osmosis options after the --tf? Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v2] Fix so that all polygons are really closed
Hi WanMil, The patch did not apply cleanly to src/uk/me/parabola/util/Java2DConverter.java revision 1862, because the file in the repository has CR+LF line endings. I believe that we should do svn propset svn:eol-style native to every (text) file in the repository. I am now testing the patch on Finland. Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Global index branch
On Sun, Feb 27, 2011 at 09:47:15AM +0100, Carlos Dávila wrote: Yes, but wouldn't it remove *all* nodes that are not part of a way? Or does it affect only the nodes of the ways filtered by the --tf instruction? Right, with --tf accept-ways it would only keep the nodes that belong to the accepted ways. I do not know about --tf reject-ways, but it is possible that you would lose all unconnected POIs in the process. Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v2] Fix so that all polygons are really closed
On Sun, Feb 27, 2011 at 11:06:22AM +0200, Marko Mäkelä wrote:
I am now testing the patch on Finland.
I got 2386 additional warnings. Some are for thin man_made=pier that
have been drawn as lines. There is man_made=* in the polygons style
file. Could we suppress the warnings for certain minor unclosed
polygons? E.g., something like this:
building=* | man_made=* | amenity=* | tourism=*
{ add mkgmap:polygon-check=false } [0x13 resolution 24]
If I disable this rule altogether, the warning count drops from 2386 to
476. That is, the selective suppression of the warnings would help a
lot.
I would demote the 270 messages about automatic closure to the INFO
level. That would leave 206 messages that need to be checked.
One more idea: you might add some extra treatment for polygons that are
more than 1 lap. For example,
http://www.openstreetmap.org/browse/way/76559964 comprised of nodes
902322231, 902322232, ..., 902322231, 902322232. The second 902322232
triggered the error.
Marko
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] POIs not generating from areas
On Sat, Feb 26, 2011 at 01:06:06PM -0600, Paul Johnson wrote: I'm wondering if we can get closed areas to generate as POIs? mkgmap --add-pois-to-areas already does so for those objects that match both the polygons and points files. Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v2] Fix so that all polygons are really closed
Marko Mäkelä (marko.mak...@iki.fi) wrote:
On Sun, Feb 27, 2011 at 11:06:22AM +0200, Marko Mäkelä wrote:
I am now testing the patch on Finland.
I got 2386 additional warnings. Some are for thin man_made=pier that
have been drawn as lines. There is man_made=* in the polygons style
file. Could we suppress the warnings for certain minor unclosed
polygons? E.g., something like this:
building=* | man_made=* | amenity=* | tourism=*
{ add mkgmap:polygon-check=false } [0x13 resolution 24]
In my custom style I have adjusted the polygons style rule to account
for this type of case:
man_made=pier area=yes [etc]
Though this depends, of course, on someone tagging the pier properly.
A mkgmap error message would help me to identify where this hasn't
been done.
--
Charlie
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Commit: r1864: Fix polygon splitting
Version 1864 was commited by wanmil on 2011-02-27 12:35:11 + (Sun, 27 Feb 2011) Fix polygon splitting Some polygons were not closed any more after splitting them due to an inappropriate usage of the PathIterator class. All conversion stuff mkgmap objects = Java2D objects are now placed in the Java2DConverter class. The background polygon is closed now. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Commit: r1865: Autoclose lines only if both endpoints are outside the bounding box
Version 1865 was commited by wanmil on 2011-02-27 12:36:31 + (Sun, 27 Feb 2011) Autoclose lines only if both endpoints are outside the bounding box ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] [TeamCity, FAILED] Build mkgmap::trunk build #1865-973
Build mkgmap::trunk build #1865-973 failed (tests failed: 1 (1 new), passed: 151). Agent: Iocaste Build results: http://teamcity.mkgmap.org.uk/viewLog.html?buildId=3366buildTypeId=bt2 Failed Tests Summary: Newly failed tests (1 test, alphabetically ordered) == func.route.SimpleRouteTest.testSize Newly failed tests details (naturally ordered) == func.route.SimpleRouteTest.testSize (new) = junit.framework.AssertionFailedError: LBL size expected:27693 but was:27672 at org.junit.Assert.fail(Assert.java:91) at org.junit.Assert.failNotEquals(Assert.java:618) at org.junit.Assert.assertEquals(Assert.java:126) at org.junit.Assert.assertEquals(Assert.java:443) at func.route.SimpleRouteTest.testSize(SimpleRouteTest.java:63) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:73) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:46) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:180) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:41) at org.junit.runners.ParentRunner$1.evaluate(ParentRunner.java:173) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31) at org.junit.runners.ParentRunner.run(ParentRunner.java:220) at junit.framework.JUnit4TestAdapter.run(JUnit4TestAdapter.java:39) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:422) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:931) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:785) Changes included (2 changes) Change 1865 by wanmil (1 file): Autoclose lines only if both endpoints are outside the bounding box Change 1864 by wanmil (4 files): Fix polygon splitting Some polygons were not closed any more after splitting them due to an inappropriate usage of the PathIterator class. All conversion stuff mkgmap objects = Java2D objects are now placed in the Java2DConverter class. The background polygon is closed now. see more information about changed files: http://teamcity.mkgmap.org.uk/viewLog.html?tab=buildChangesDivbuildId=3366buildTypeId=bt2 Configure email notifications: http://teamcity.mkgmap.org.uk/profile.html?init=1tab=userNotifications ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v2] Fix so that all polygons are really closed
Moin, Marko Mäkelä schrieb am 27.02.2011 10:32: I got 2386 additional warnings. Some are for thin man_made=pier that have been drawn as lines. There is man_made=* in the polygons style file. I have not tested the polygonclose_v2.patch but it sounds like it has the inverse effect of the previous restrict_polygon_v1.patch, which sounds like a very bad idea to me. In the OSM data we have sometimes identical tags for line objects and for area objects. The restrict_polygon_v1.patch was build, so that the polygon rules were only applied, if the OSM-way is closed. Now the new patch seems to close automatically all ambigous ways, making the previous problem even worse. Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [Patch] MapSource installer improvements v1
On 2/27/2011 9:26 AM, Steve Ratcliffe wrote: + seriesName = args.get(family-name, OSM map); OK, but this is a bit confusing... it needs to be + familyName = args.get(family-name, OSM map); and then any other change that follows on from that. Agreed. I did it afterward in my v2 of the patch. I am still working on it to include more of Minko's suggestion + some ideas of my own. Hopefully I can post something later today. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Global index branch
There is a section MDR8 which I added which is an index of the first four letters of the street name into the streets section. Now I think that would probably work OK, but there is one problem. In one case there is Calle spelt with a C-cedilla Çalle (is that even correct?). Anyway when I search back to find the first street name beginning with CALL, I stop after ÇALLE REAL because the search treats it as a different letter and so the first street that is found is CALLE REAL (A-8076) Hi Steve, I'm not deeply involved in the current index code, but should the accented 'c' not beeing converted to a standard 'c' in the index? If I enter the street names in my etrex, I can enter the base character, i will get all streets which contain at this position special characters. In german I can enter the character 'o' and even umlauts like 'ö' will be found. So I think at this index there should be the the special charcters converted to the base characters. Regards, Johann ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [Patch] MapSource installer improvements v1
The family name is stored in the mapsource windows registry and is commonly used as directory name. It's also the name of the map that you see in your gps. The series name is the name that you see in the drop down list in mapsource. At the moment the series name is used for all the nsis parameters, but I think it makes more sense to use the family name for this. This makes it possible to use the series name in combination with a version or date stamp (eg osm map version 27-02-2011) so you can see in Mapsource from what date your mapversion is (the family name isnt shown in MS). It will also mean that you always store the map in the same folder, because you can keep the family name the same every time. Cheers, Minko -- Steve wrote OK, but this is a bit confusing... it needs to be + familyName = args.get(family-name, OSM map); and then any other change that follows on from that. But what is the real problem here? Do we use the terms family-name and series-name differently from everyone else? (I was never sure which was which). ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v2] Fix so that all polygons are really closed
it's the other way round. The patch tests for all unclosed ways that are assigned with a garmin polygon type if both endpoints are outside the bounding box. Only in this case the polygons are closed automatically. Ok, perhaps take an example, so that I can understand what patch has which effect. There is an OSM-way with Tags: tagA=valueA and Nodes: node1 node2 node3 (node1 /= node3) In the polygon style there is a line tagA=valueA [0x01 continue] And in the lines style there is a line tagA=valueA [0x02 continue] With r1733 this will result in two elements in the garmin map: 1. A triangular shape with the type 0x01 and the corners node1, node2 and node3. 2. A line with the type 0x02 from node1 via node2 to node3. With r1733 and restrict_polygon_v1.patch this will result only in one element in the garmin map: A line with the type 0x02 from node1 via node2 to node3. What will be the result of r1733 and polygonclose_v2.patch? What will be the result of r1733 and polygonclose_v2.patch and restrict_polygon_v1.patch? (Would this make any sense at all?) Gruss Torsten I have committed the (slightly changed) polygonclose_v2.patch which is now r1865. Your example will result in 1. line with 0x01 2. a) nothing more if node1 or node2 is within the tiles bounding box b) a polygon 0x02 if node1 and node2 is outside or on the tiles bounding box. Both patches do not make sense because if appliying restrict_polygon_v1.patch the code of polygonclose_v2.patch will never be reached. WanMil ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v2] Fix so that all polygons are really closed
WanMil schrieb am 27.02.2011 16:53: Your example will result in 1. line with 0x01 2. a) nothing more if node1 or node2 is within the tiles bounding box b) a polygon 0x02 if node1 and node2 is outside or on the tiles bounding box. Ok, I will try out r1865 when it is availbale as a download. But in my opinion 2.b) is a fault: If the polygon is not closed in the OSM data, it shouldn't be closed by mkgmap, no matter whether the start and end nodes are inside or outside the bounding box. Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] [Patch] MapSource installer improvements v3
Hello,
Attached is the new (and hopefully final) version of the patch:
* uses family name for directory name
* map can now be uninstalled from Add/Remove Programs (WinXP) or
Programs and Features (Vista/Win7)
* uninstalls map if already installed
* installer and license files are now generated from templates for
easier maintenance
As for checking MapSource/BaseCamp, I am wondering how much an
issue it is to install a map while they are open (except from having to
restart them to see the new map). My main concern here is that if we
check if they are running, the files cannot be compiled with NSIS out of
the box anymore but need a plug-in to be installed.
Thanks,
N.
Index: build.xml
===
--- build.xml (revision 1862)
+++ build.xml (working copy)
@@ -116,6 +116,7 @@
include name=**/*.trans/
include name=styles/**/
include name=help/**/
+ include name=installer/**/
exclude name=**/.*/
/fileset
fileset dir=src
@@ -197,6 +198,7 @@
include name=**/*.trans/
include name=styles/**/
include name=help/**/
+ include name=installer/**/
/jar
copy todir=${dist}/doc
Index: resources/installer/installer_template.nsi
===
--- resources/installer/installer_template.nsi (revision 0)
+++ resources/installer/installer_template.nsi (revision 0)
@@ -0,0 +1,90 @@
+; INSERT_DEFINES_HERE
+
+SetCompressor /SOLID lzma
+
+; Includes
+!include MUI2.nsh
+
+; Installer pages
+!insertmacro MUI_PAGE_WELCOME
+!insertmacro MUI_PAGE_LICENSE Test_license.txt
+!insertmacro MUI_PAGE_DIRECTORY
+!insertmacro MUI_PAGE_INSTFILES
+!insertmacro MUI_PAGE_FINISH
+
+; Uninstaller pages
+!define MUI_UNPAGE_INSTFILES
+
+!insertmacro MUI_LANGUAGE English
+
+Name ${INSTALLER_DESCRIPTION}
+OutFile ${INSTALLER_NAME}.exe
+InstallDir ${DEFAULT_DIR}
+
+Function .onInit
+ ; Uninstall before installing (code from
http://nsis.sourceforge.net/Auto-uninstall_old_before_installing_new )
+ ReadRegStr $R0 HKLM \
+ Software\Microsoft\Windows\CurrentVersion\Uninstall\${REG_KEY}
UninstallString
+ StrCmp $R0 done
+
+ MessageBox MB_OKCANCEL|MB_ICONEXCLAMATION ${INSTALLER_NAME} is already
installed. $\n$\nClick `OK` to remove the previous version or `Cancel` to
cancel this upgrade. IDOK uninst
+ Abort
+
+;Run the uninstaller
+uninst:
+ ClearErrors
+ ExecWait '$R0 _?=$INSTDIR' ;Do not copy the uninstaller to a temp file
+
+ IfErrors no_remove_uninstaller done
+;You can either use Delete /REBOOTOK in the uninstaller or add some code
+;here to remove the uninstaller. Use a registry key to check
+;whether the user has chosen to uninstall. If you are using an uninstaller
+;components page, make sure all sections are uninstalled.
+ no_remove_uninstaller:
+
+done:
+
+FunctionEnd
+
+Section MainSection SectionMain
+; Files to be installed
+ SetOutPath $INSTDIR
+; INSERT_ADDED_FILES_HERE
+
+; Create MapSource registry keys
+; INSERT_REGBIN_HERE
+ WriteRegStr HKLM SOFTWARE\Garmin\MapSource\Families\${REG_KEY} IDX
$INSTDIR\${MAPNAME}.mdx
+ WriteRegStr HKLM SOFTWARE\Garmin\MapSource\Families\${REG_KEY} MDR
$INSTDIR\${MAPNAME}_mdr.img
+ WriteRegStr HKLM
SOFTWARE\Garmin\MapSource\Families\${REG_KEY}\${PRODUCT_ID} BMAP
$INSTDIR\${MAPNAME}.img
+ WriteRegStr HKLM
SOFTWARE\Garmin\MapSource\Families\${REG_KEY}\${PRODUCT_ID} LOC $INSTDIR
+ WriteRegStr HKLM
SOFTWARE\Garmin\MapSource\Families\${REG_KEY}\${PRODUCT_ID} TDB
$INSTDIR\${MAPNAME}.tdb
+
+; Write uninstaller
+ WriteUninstaller $INSTDIR\Uninstall.exe
+
+; Create uninstaller registry keys
+ WriteRegStr HKLM
SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\${REG_KEY} DisplayName
$(^Name)
+ WriteRegStr HKLM
SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\${REG_KEY}
UninstallString $INSTDIR\Uninstall.exe
+ WriteRegDWORD HKLM
SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\${REG_KEY} NoModify 1
+
+SectionEnd
+
+Section Uninstall
+; Files to be uninstalled
+; INSERT_REMOVED_FILES_HERE
+
+ RmDir $INSTDIR
+
+; Registry cleanup
+ DeleteRegValue HKLM SOFTWARE\Garmin\MapSource\Families\${REG_KEY} ID
+ DeleteRegValue HKLM SOFTWARE\Garmin\MapSource\Families\${REG_KEY} IDX
+ DeleteRegValue HKLM SOFTWARE\Garmin\MapSource\Families\${REG_KEY} MDR
+ DeleteRegValue HKLM
SOFTWARE\Garmin\MapSource\Families\${REG_KEY}\${PRODUCT_ID} BMAP
+ DeleteRegValue HKLM
SOFTWARE\Garmin\MapSource\Families\${REG_KEY}\${PRODUCT_ID} LOC
+ DeleteRegValue HKLM
SOFTWARE\Garmin\MapSource\Families\${REG_KEY}\${PRODUCT_ID} TDB
+ DeleteRegKey /IfEmpty HKLM
SOFTWARE\Garmin\MapSource\Families\${REG_KEY}\${PRODUCT_ID}
+
Re: [mkgmap-dev] splitter error : java.lang.NoClassDefFoundError: crosby/binary/file/BlockReaderAdapter
Le 27/02/2011 18:24, Henning Scholland a écrit : I've downloaded splitter -r164, but got the same result. Do not know where my mistake is Francois Did you also copied lib directory next to splitter.jar? Bingo, you did it. Now it works as before. Great and thank you. Francois -- ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v2] Fix so that all polygons are really closed
On Sun, Feb 27, 2011 at 12:59:09PM +0100, WanMil wrote: If I disable this rule altogether, the warning count drops from 2386 to 476. That is, the selective suppression of the warnings would help a lot. Mmh, I am not a big fan of suppressing warning messages. But I see that you have the problem that you only want to use man_made=pier with polygons. If you add a dead rule to the line style you will loose all man_made=pier. Would it help you if I add the tags of the way to the warning message? Then you could easily filter the message. I see that you implemented the tag list printout. It might be good enough. One more idea: you might add some extra treatment for polygons that are more than 1 lap. For example, http://www.openstreetmap.org/browse/way/76559964 comprised of nodes 902322231, 902322232, ..., 902322231, 902322232. The second 902322232 triggered the error. Is this really a big problem? It is an error in the OSM data and just in case this does not happen very often we should not support such errors by fixing them automatically. It is probably not a big problem, and I was not thinking that we should try to fix any garbage automatically. It could be nice to have the message distinguish incorrectly closed polygons from unclosed polygons. It took me some time to figure out the problem. I was expecting to see a gap between some points, but there was none. Only after I split the way in JOSM, the highlighting of the area hinted me where the starting point was. Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Global index branch
Hello On 26/02/11 16:46, ValentinAK wrote: What about Russian? Many users in Russia use mkgmap with -charset:cp1251 or -code-page:1251. The index-branch version 1861 does not work correctly with the Russian character set. To support code pages other than 1252 we need to create files that describe how the characters are sorted. The following will be of interest to just about everyone. This is specified in the SRT file and I have created a text file format that can be used to create these files. However I don't know 100% how it works, so some things have to be guessed. At the top of the file there are the following: # The code page codepage 1251 # I have no idea what these are for, but they are important # and if they are not present everywhere they should be then # things will not work. I don't know if they simply identify the # sort or have some other meaning. id1 7 id2 2 # Any descriptive text description Russian Sort Then there are the characters and how they should sort. The file itself is in utf-8, but characters can be represented either by themselves (in utf-8) or by a two character hexadecimal representation of their value in the target character set. Every different letter is on its own line, eg: code A code B Characters that differ only in case are separated by a comma: code a, A Letters that differ only by accent are separated by a semi-colon code a, A; á, Á Today I found this site: http://www.collation-charts.org/ which is a good source of information. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Global index branch
Hi I'm not deeply involved in the current index code, but should the accented 'c' not beeing converted to a standard 'c' in the index? Probably yes for MDR8, but for the street index, no. If I enter the street names in my etrex, I can enter the base character, i will get all streets which contain at this position special characters. In german I can enter the character 'o' and even umlauts like 'ö' will be found. So I think at this index there should be the the special charcters converted to the base characters. All the accented characters are sorted together, almost as though they were the same character, so that is why that works. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
