[PATCH] Allow ~ and friends at top level

Steve, This patch seems to work for me, but as I am not familiar with the pattern matching in the mkgmap style engine, I would like to ask for review and approval. Best regards, Marko

Hi Felix, On Sat, Jan 16, 2010 at 09:02:05PM +0100, Felix Hartmann wrote:
On 16.01.2010 20:59, Marko Mäkelä wrote:
+natural ~ 'wetland\|marsh\|mud' [0x51 resolution 20]
Is there a performance increase (or maybe memory usage decrease) vs: natural=wetland | natural=marsh | natural=mud [0x51 resolution 20]
????
You're right, I should have timed it. Sorry, I do not know how to measure memory usage, but I would not expect any significant difference there. I tried the attached optimizations to the default style. Without the optimizations, it took this long to compile my three tiles of Finland: real 3m53.333s user 4m23.332s sys 0m7.752s With the style optimized with top-level regexp matches, the compilation is very slightly faster: real 3m50.705s user 4m21.924s sys 0m7.744s Note that I had the Ondemand CPU frequency scaling governor enabled. For some reason, the generated maps are of different size: -rw-r--r-- 1 marko marko 45475840 16.1. 22:17 gmapsupp.img -rw-r--r-- 1 marko marko 45423616 16.1. 22:12 gmapsupp-relop.img I did not investigate this difference yet? Can you give it a spin on your system? Best regards, Marko

On 16.01.2010 21:25, Marko Mäkelä wrote:
Hi Felix,
On Sat, Jan 16, 2010 at 09:02:05PM +0100, Felix Hartmann wrote:
On 16.01.2010 20:59, Marko Mäkelä wrote:
+natural ~ 'wetland\|marsh\|mud' [0x51 resolution 20]
Is there a performance increase (or maybe memory usage decrease) vs: natural=wetland | natural=marsh | natural=mud [0x51 resolution 20]
????
You're right, I should have timed it. Sorry, I do not know how to measure memory usage, but I would not expect any significant difference there.
I tried the attached optimizations to the default style. Without the optimizations, it took this long to compile my three tiles of Finland:
real 3m53.333s user 4m23.332s sys 0m7.752s
With the style optimized with top-level regexp matches, the compilation is very slightly faster:
real 3m50.705s user 4m21.924s sys 0m7.744s
Note that I had the Ondemand CPU frequency scaling governor enabled.
For some reason, the generated maps are of different size:
-rw-r--r-- 1 marko marko 45475840 16.1. 22:17 gmapsupp.img -rw-r--r-- 1 marko marko 45423616 16.1. 22:12 gmapsupp-relop.img
I did not investigate this difference yet?
Can you give it a spin on your system?
okay, I changed my whole polygons file to using your notation wherever possible, and ended up 6 minutes 10 seconds instead of 6 minutes 11 seconds for a compilation of the Netherlands, so I cannot see any speed difference. Retried on Italy and saved about 3% of time. However I also lost some polygons, so something definitely does not work with your patch!!!! I lost all of the following new: place ~ 'town\|suburb\village' [0x03 resolution 21] old: place=suburb | place=town | place=village [0x03 resolution 21] I am already using the "final" patch by wanmil on trunk branch. ........................... Your testing could well be different because you were putting two lines into one like key1=123 key1=456 whereas I changed from key1=123 | key1=456 I did not however also that the maps rendered became smaller. I'm still trying to find out the differences.
Best regards,
Marko
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Hi Felix, Thank you for testing my patch. In any case, I will try to figure out what caused the size difference for me. Even if the patch does not seem to bring much CPU-wise, the compact notation could be useful in some cases. But as your example shows, the downside of the compactness would be extra care needed when editing rules: On Sun, Jan 17, 2010 at 12:18:07AM +0100, Felix Hartmann wrote:
I lost all of the following new: place ~ 'town\|suburb\village' [0x03 resolution 21] old: place=suburb | place=town | place=village [0x03 resolution 21]
It should be suburb\|village, not suburb\village. You should have got points for place=town, but there probably were no place="suburb\village" in the input. :-) (I don't even know what the \v would translate into in this case. Probably just 'v', but it could be 0x0b (vertical tab) too.
Your testing could well be different because you were putting two lines into one like key1=123 key1=456
whereas I changed from key1=123 | key1=456
I don't know if this really makes a difference. A comment in the method that I changed suggested that the top-level | would be split earlier. It could very well be equivalent to writing separate rules for each top-level | operand. Best regards, Marko

On 17.01.2010 11:20, Marko Mäkelä wrote:
Hi Felix,
Thank you for testing my patch. In any case, I will try to figure out what caused the size difference for me. Even if the patch does not seem to bring much CPU-wise, the compact notation could be useful in some cases. But as your example shows, the downside of the compactness would be extra care needed when editing rules:
On Sun, Jan 17, 2010 at 12:18:07AM +0100, Felix Hartmann wrote:
I lost all of the following new: place ~ 'town\|suburb\village' [0x03 resolution 21] old: place=suburb | place=town | place=village [0x03 resolution 21]
It should be suburb\|village, not suburb\village. You should have got points for place=town, but there probably were no place="suburb\village" in the input. :-) (I don't even know what the \v would translate into in this case. Probably just 'v', but it could be 0x0b (vertical tab) too.
Well however even without typo I'm still missing them!!!!! Using: /landuse ~ 'residential\|residental' [0x03 resolution 21] place ~ 'town\|suburb\|village\|hamlet' [0x03 resolution 21]/ There is absolutely no 0x03 in my map.... If I use instead /landuse=residential | landuse=residental [0x03 resolution 21] place=suburb | place=village | place=town [0x03 resolution 21]/ it renders fine. Something fundamentally fucks up in with your patch or there is again some typo that I made?

Hello. It's some months I noticed a problem. Very often building Italy and using lates splitter (97..103) and lates mkgmap (varies) the map has some routing problem. In fact trying complex routes (example: from a side of Rome to the other), mapsource is sometimes unable to find the route and stops with an error. If I take the same italy OSM data file and I split with the very old splitter (I do not know the version, it's the 51 Kbyte jar). The problem does not appear. It is not related to style (my stile and default presents the same issue). This is the command line I use (part of a cmd script on Windows XP): ... java -enableassertions -Xmx1000m -jar ..\bin\splitter.jar --mapid=66%FID%001 --max-nodes=1000000 ..\OSM-Data\%osmfile% java -enableassertions -Xmx1000m -jar ..\bin\mkgmap.jar --code-page=1252 --country-name="%country%" --latin1 --family-id=%FID% --mapname=66%FID%001 --overview-mapname=66%FID%000 --tdbfile --series-name="OSM-%country%" --family-name="OpenStreetMap: %country%" --road-name-pois --add-pois-to-areas --no-poi-address --ignore-maxspeeds --remove-short-arcs --preserve-element-order --style-file=..\bin\resources\styles\ --style=%style% --description="%country%" --route --net --gmapsupp -c template.args ... Is is a known problem? Ciao, Marco.
participants (3)
-
Felix Hartmann
-
Marco Certelli
-
Marko Mäkelä