Re: [mkgmap-dev] Commit r4365: code cleanup, no change in output expected

Hello Gerd, thanks, will check the new version in the evening and yes, the other lines are debug output from the style file. Regards, Uli -- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html ___ mkgmap-dev mailing list

Re: [mkgmap-dev] Commit r4365: code cleanup, no change in output expected

Hello, with this latest build i get the following errors: ... Way 236957659 Small wood Way 265284491 Small forest SCHWERWIEGEND (ExtNumbers): 66923015.o5m: internal error, house has wrong segment, road id=109200284, Wiedau house 33(3) http://www.openstreetmap.org/way/291590539 SCHWERWIEGEND

Re: [mkgmap-dev] Commit r4291: NET-without-NOD-v1.patch: Improve polish (*.mp) reader

Hi Gerd, thanks for the information, with version 4290 there is no problem. Best regards, Uli -- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk

Re: [mkgmap-dev] Commit r4291: NET-without-NOD-v1.patch: Improve polish (*.mp) reader

Hello, unfortunately i get tons of following errors with the latest build: SCHWERWIEGEND (RoadDef): 66923027.o5m: internal error? The nodeCount doesn't match value calculated by RoadNetWork: (http://www.openstreetmap.org/browse/way/24010392) This is new, with version 4289 there is no problem.

Re: [mkgmap-dev] Server Down ?

Here is an alternative source from Thomas Kukuk: http://osm.thkukuk.de/data/ But i think this is a private server, so don't stress it too much. Best regards, Uli -- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html

Re: [mkgmap-dev] Performance hints for Java JRE 9 + 10

Hi, i have comparable performance to former Java 8 and considerable lower memory consumption, when i use the OpenJDK 10 with the Eclipse OpenJ9 VM from AdoptOpenJDK! It is not officially released jet, but i use it with great success. If you want to try, you'll have to use the nightly builds from

Re: [mkgmap-dev] Commit r3976: ShapeSplitFix by Ticker Berkin

Thank you, i'll check later this day! -- View this message in context: http://gis.19327.n8.nabble.com/Commit-r3976-ShapeSplitFix-by-Ticker-Berkin-tp5899976p5900069.html Sent from the Mkgmap Development mailing list archive at Nabble.com. ___

Re: [mkgmap-dev] Commit r3976: ShapeSplitFix by Ticker Berkin

With the latest build (3976) i get the following issues when compiling a map: SCHWERWIEGEND (StyledConverter): 66923093.o5m: Found multiple points with equal coords as CoordPOI at http://www.openstreetmap.org/? mlat=48.103906=11.425810=17 SCHWERWIEGEND (StyledConverter): 66923093.o5m: Found

[mkgmap-dev] Strange code in mkgmap?

Hi there, examining the code of mkgmap i found some strange lines. In /mkgmap/src/uk/me/parabola/util/ShapeSplitter.java Line 330: This is redundant? In /mkgmap/src/uk/me/parabola/mkgmap/osmstyle/housenumber/HousenumberGenerator.java Line 1537+1538: This was already tested 6 lines above, so

Re: [mkgmap-dev] Commit r3809: overlay major roundabout ways (0x0c) with 0x10801..0x10804

Just wanted to post a patch with: ... if (usableShapes.size() > 1) { ...(calculate)... } return mergedShapes; Then i saw your post with a similar patch. Confirmed, is running now! -- View this message in context:

Re: [mkgmap-dev] Commit r3809: overlay major roundabout ways (0x0c) with 0x10801..0x10804

Version 3808 also fails with the exact same error. -- View this message in context: http://gis.19327.n8.nabble.com/Commit-r3809-overlay-major-roundabout-ways-0x0c-with-0x10801-0x10804-tp5891426p5891460.html Sent from the Mkgmap Development mailing list archive at Nabble.com.

Re: [mkgmap-dev] Commit r3809: overlay major roundabout ways (0x0c) with 0x10801..0x10804

With this latest version of mkgmap i get the following error: java.lang.IndexOutOfBoundsException: Index: 0, Size: 0 at java.util.ArrayList.rangeCheck(ArrayList.java:653) at java.util.ArrayList.get(ArrayList.java:429) at

Re: [mkgmap-dev] Automatic build system down?

Well, within 1 minute of writing it works again - thanks! ;) -- View this message in context: http://gis.19327.n8.nabble.com/Automatic-build-system-down-tp5891425p5891438.html Sent from the Mkgmap Development mailing list archive at Nabble.com. ___

Re: [mkgmap-dev] Automatic build system down?

SVN seems to be down? It is not accessible via eclipse or websvn. See: http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap=3809 Best regards, Uli -- View this message in context: http://gis.19327.n8.nabble.com/Automatic-build-system-down-tp5891425p5891437.html Sent from the Mkgmap

Re: [mkgmap-dev] Splitter r483 in refactoring2 branch

Hi Gerd, thanks for clearing things up. Just now testing a complete run with splitter 501 and mkgmap 3706. Splitter has already run thru and now mkgmap is doing its rounds. Seems ok so far! :thumbsup: :) Uli -- View this message in context:

Re: [mkgmap-dev] Splitter r483 in refactoring2 branch

Hi Gerd, some time ago you mentioned, the new splitter branch isn't compatible with the current mkgmap version. Are these differences not important anymore and they can be used in combination? Regards, Uli -- View this message in context:

Re: [mkgmap-dev] splitter: issues when splitting planet

Hi Gerd, sorry for being off topic, but the following patch is permanently in my workspace and begins to be a real pita... ;) Maybe it could be included in the next splitter release? Best regards, Uli src.patch -- View this message

Re: [mkgmap-dev] Move to Java 1.8

Gerd Petermann wrote > Hi Uli, > > thanks for the patch. I tried it and found no significant change in run > time > or memory usage. > My test case: Compile 9 tiles (a part of the Britisch Isles) (with > --max-jobs on 4 cores) > In what scenario do you think that the stream methods should save

Re: [mkgmap-dev] Move to Java 1.8

Gerd Petermann wrote > Hi Uli, > > thanks for the hint. I'll experiment with this in future. At the moment I > don't know > of any bottlenecks which could be solved by this. > > Gerd Hi Gerd, yesterday evening i played a little bit with list streaming and found an (albeit small) speed increase

Re: [mkgmap-dev] Commit r3687: Remove the forced jdk1.7 target.

Steve Ratcliffe wrote > Thanks! What about org.eclipse.jdt.core.compiler.codegen.targetPlatform > should that be 1.8 too? > > Best wishes > > ..Steve Well, i think it couldn't hurt. I have set all options to use the standard jvm, which defaults to Java 8 in my eclipse. The only manual settings

Re: [mkgmap-dev] Move to Java 1.8

Gerd Petermann wrote > Hi Uli, > > do you have an example for me? > > Gerd Hi Gerd, i'll have to look deeper into the source code, but i assume, mkgmap also uses list operations in the calculations? I had major performance gains in a commercial project, migrating bigger and longish list

Re: [mkgmap-dev] Commit r3687: Remove the forced jdk1.7 target.

Sorry to interrupt, but the "org.eclipse.jdt.core.prefs" are still on Java 1.7, esp. "org.eclipse.jdt.core.compiler.source" and "org.eclipse.jdt.core.compiler.compliance". To really use the Java 8 features, both have to be on 1.8. Best regards, Uli -- View this message in context:

Re: [mkgmap-dev] Move to Java 1.8

I already use Java 8 nearly since the beginning and have checked out the workspace for splitter and mkgmap into eclipse Neon without problems. My local project is modified to produce Java 8 output. With this change it would be possible to replace a lot of list operations with the new streaming

Re: [mkgmap-dev] dest_hint=true Problem

Hi Gerd, thank you! I will try again tonight and also try to fix the code for processing the exit and destination hints in the style! Best regards, Uli -- View this message in context: http://gis.19327.n5.nabble.com/dest-hint-true-Problem-tp5871078p5871096.html Sent from the Mkgmap

Re: [mkgmap-dev] dest_hint=true Problem

I am absolutely sure, it is the right style in question. I don't get *any* warnings using mkgmap r3674, only some test output like "Small wood" or "Small forest", which are echoed in the include files, e. g. landuse_polygons. I double checked, this is the style in use. :? -- View this message

Re: [mkgmap-dev] dest_hint=true Problem

Hi Gerd, i even searched only for "dest_hint" and found nothing. I attach the style in question, cause i can't find another occurrence. Best regards, Uli Attachment: Style.7z -- View this message in context:

[mkgmap-dev] dest_hint=true Problem

Hi there, with the latest version of mkgmap (r3675) i always get the following error: SCHWERWIEGEND (StyledConverter): 66923011.o5m: At least one 'lines' rule in the style contains the expression mkgmap:dest_hint=true, it should be changed to mkgmap:dest_hint=* I changed absolutely every

Re: [mkgmap-dev] bicycle=use_sidepath

Forgive me, but since routing problems are just discussed here, i also have a problem with bicycle paths: Nearly every time i leave the calculated route for car navigation and the Garmin starts to recalculate the route, it assumes, i'm driving on a bicycle way on the side of the street and it

Re: [mkgmap-dev] bicycle=use_sidepath

Hello Thorsten, no, i don't have lock on road enabled. I always thought, this option is only cosmetically changing the position of the marker onto the nearest road. Does this change the way the unit routes? Even if so and the position is nearer to the bicycle way than to the street, wouldn't it

Re: [mkgmap-dev] bicycle=use_sidepath

Hi fellows, thanks a lot for the answers. In the future i will switch on lock on road for routing and switch it off for Geocaching. ;) Thanks again and best regards, Uli -- View this message in context: http://gis.19327.n5.nabble.com/bicycle-use-sidepath-tp5852510p5852654.html Sent from the

Re: [mkgmap-dev] Commit: r3597: corrections for process-exits option

Hi Gerd, just to confirm: Version 3598 works correctly on the same dataset. Thank you for this really quick response! :) Best regards, Uli -- View this message in context: http://gis.19327.n5.nabble.com/Commit-r3597-corrections-for-process-exits-option-tp5844899p5845001.html Sent from the

Re: [mkgmap-dev] Commit: r3597: corrections for process-exits option

With this latest version i get the following exception: java.lang.NullPointerException at uk.me.parabola.mkgmap.reader.osm.LinkDestinationHook.processWays(Link DestinationHook.java:487) at uk.me.parabola.mkgmap.reader.osm.LinkDestinationHook.end(LinkDestinat ionHook.java:737)

[mkgmap-dev] Strange Exception in Mkgmap

Hi, i get a strange Exception in mkgmap: SCHWERWIEGEND (StyledConverter): 66923072.o5m: Found multiple points with equal coords as CoordPOI at http://www.openstreetmap.org/?mlat=52.343451mlon=9.904486 zoom=17 SCHWERWIEGEND (StyledConverter): 66923072.o5m: Found multiple points with equal coords

Re: [mkgmap-dev] Driving on Trail

GerdP wrote Hi Brian, I never saw this text on my Oregon. If I got you right, you have two routable lines for the same OSM way, the device routes you over the way for the car, but it displays the info for the sidewalk. Could this be the reason? Gerd Hi Gerd, i can second this

Re: [mkgmap-dev] NPE with mkgmap 3320

Hi Gerd, now it works multithreaded on JDK 8. Thanks again! Uli -- View this message in context: http://gis.19327.n5.nabble.com/NPE-with-mkgmap-3320-tp5813472p5823529.html Sent from the Mkgmap Development mailing list archive at Nabble.com. ___

Re: [mkgmap-dev] NPE with mkgmap 3344!

BTW: Since there is a check against City object being null before the compare method: // TODO: look at what this is doing... if(city != null other.city != null) return city.getName().compareTo(other.city.getName()); --- Here happens the NPE if (hashCode() == other.hashCode())

Re: [mkgmap-dev] NPE with mkgmap 3320

Hi Gerd, this is good news! I'll use my single threaded workaround for the time being. When a patch or a different approach is committed, i will run again multi threaded. I was sure that the error also happened with Java 7, but now i'm not so sure anymore. Maybe, i had already switched to Java

Re: [mkgmap-dev] NPE with mkgmap 3320

Last night this error happened again at the same spot. The remedy is still the same: Run only one thread or declare the method synchronized. I still think, something is not right there... java.lang.NullPointerException at uk.me.parabola.imgfmt.app.net.RoadDef.compareTo(RoadDef.java:700)

Re: [mkgmap-dev] NPE with mkgmap 3344!

Forgot: With actual version 3344. -- View this message in context: http://gis.19327.n5.nabble.com/NPE-with-mkgmap-3320-tp5813472p5823285.html Sent from the Mkgmap Development mailing list archive at Nabble.com. ___ mkgmap-dev mailing list

Re: [mkgmap-dev] NPE with mkgmap 3344!

Hi Gerd, i use the following command to start mkgmap: start /belownormal /b /wait java -XX:+AggressiveOpts -XX:+AggressiveHeap -XX:+ParallelRefProcEnabled -Xmx1400m -jar ..\bin\mkgmap.jar --max-jobs=2 --generate-sea --country-name=%country% --family-id=%FID% --mapname=66%FID%001

[mkgmap-dev] NPE with mkgmap 3320

With the latest versions (tried, back until 3316) of mkgmap i'm getting a NPE with a new setup on an older 32Bit XP Machine: java.lang.NullPointerException at uk.me.parabola.imgfmt.app.net.RoadDef.compareTo(RoadDef.java:700) at

Re: [mkgmap-dev] [Patch v1] improve splitter

Hi Gerd, i splat ( ;-) ) Germany.o5m with --max-nodes=200 per tile. With version 389 i get 96 tiles, with the improved version i get only 91 tiles with extraordinary equality in size, also the final gmapsupp.img is smaller. I think, it's a good improvement! Best regards, Uli -- View this

Re: [mkgmap-dev] error handling in splitter

Hi Gerd, this sounds very reasonable! How about implementing this like the way mkgmap handles it? If given the option --keep-going it will continue as splitter does now and the new default would be to stop processing? BTW: Last time i suspected mkgmap to produce bad maps, it was because of a

Re: [mkgmap-dev] error handling in splitter

Hi Gerd, i just thought of some kind of backward compatibility. In my opinion i see no reason for splitter to continue processing corrupted data. BTW: Could be there are some files missing for checkin? Somehow, the new splitter builds do not appear for download. Uli -- View this message in

Re: [mkgmap-dev] error handling in splitter

Hi Gerd, you are right, i missed, it's a branch! *handtoforehead* ;) Uli -- View this message in context: http://gis.19327.n5.nabble.com/error-handling-in-splitter-tp5806188p5806213.html Sent from the Mkgmap Development mailing list archive at Nabble.com.

Re: [mkgmap-dev] Commit: r3269: enlarge list of special routable types to

Even after ~6 hours the build does not appear for download? :? -- View this message in context: http://gis.19327.n5.nabble.com/Commit-r3269-enlarge-list-of-special-routable-types-to-tp5805917p5805948.html Sent from the Mkgmap Development mailing list archive at Nabble.com.

Re: [mkgmap-dev] Commit: r3269: enlarge list of special routable types to

Thank you! :) -- View this message in context: http://gis.19327.n5.nabble.com/Commit-r3269-enlarge-list-of-special-routable-types-to-tp5805917p5805952.html Sent from the Mkgmap Development mailing list archive at Nabble.com. ___ mkgmap-dev mailing

Re: [mkgmap-dev] --check-styles

BTW: The message is still present in version 3258. ;) -- View this message in context: http://gis.19327.n5.nabble.com/check-styles-tp5805213p5805352.html Sent from the Mkgmap Development mailing list archive at Nabble.com. ___ mkgmap-dev mailing list

[mkgmap-dev] --check-styles

Hi, with the latest version (3248) of mkgmap i get a lot of following errors: SCHWERWIEGEND (StyledConverter): 66923125.o5m: Non-routable type 0x26 in combina tion with road_class/road_speed used for routable map. Try --check-styles to che ck the style. When i run checkstyles, it complains

Re: [mkgmap-dev] --check-styles

Thanks for the info! -- View this message in context: http://gis.19327.n5.nabble.com/check-styles-tp5805213p5805225.html Sent from the Mkgmap Development mailing list archive at Nabble.com. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk

Re: [mkgmap-dev] Commit: r3200: Reapply 3198 as svn move

Hi again, now even version 3193 produces garbled display and i start to consider my dataset as being corrupted. Splitter 321 also gives way more missing nodes messages as usual, so i download a new dataset now and retry version 3200. Sorry for the confusion... -- View this message in context:

Re: [mkgmap-dev] Commit: r3200: Reapply 3198 as svn move

GerdP wrote Hi Uli, no problem, I expected something like that ;-) Gerd Hi Gerd, confirmed now, with new dataset version 3200 is fine, no garbled display on etrex Vista HCx anymore. I'm very sorry for blaming mkgmap for this, but in the same time don't understand, how the dataset could

Re: [mkgmap-dev] Commit: r3200: Reapply 3198 as svn move

Hi Gerd, i'm using osmconvert since long time to cut a Germany excerpt from the Europe excerpt from the GeoFabrik. Osmconvert, even in the 32 bits version, has no problems with files greater 4GB. The Europe extract is 10GB and the excerpt, containing Germany with a 50 km surrounding and the

Re: [mkgmap-dev] Commit: r3200: Reapply 3198 as svn move

This version results in a totally garbled display on an etrex Vista HCx. No problem with version 3193. :? -- View this message in context: http://gis.19327.n5.nabble.com/Commit-r3200-Reapply-3198-as-svn-move-tp5803603p5803668.html Sent from the Mkgmap Development mailing list archive at

Re: [mkgmap-dev] Commit: r3200: Reapply 3198 as svn move

Nope, using version 3200 and the ignore-parameter only made a little smaller file, but the display remained garbled. Will try version 3195 now... Additionally this error was displayed: SCHWERWIEGEND (ShapeMergeFilter): 66923104.o5m: ignoring shape with id 273262452 and type 0x13 at resolution

Re: [mkgmap-dev] Commit: r3200: Reapply 3198 as svn move

Interestingly with version 3195 i get the following error: # # A fatal error has been detected by the Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x53f9f280, pid=1528, tid=6448 # # JRE version:

Re: [mkgmap-dev] Commit: r3200: Reapply 3198 as svn move

Yes, it is a Java 8 platform, but that's no problem, because it is downwards compatible. After a reboot i'll check version 3195 again, running now... -- View this message in context: http://gis.19327.n5.nabble.com/Commit-r3200-Reapply-3198-as-svn-move-tp5803603p5803678.html Sent from the

Re: [mkgmap-dev] Commit: r3200: Reapply 3198 as svn move

Version 3195 also creates a garbled display on etrex Vista HCx. Will now use version 3193 until further notice. -- View this message in context: http://gis.19327.n5.nabble.com/Commit-r3200-Reapply-3198-as-svn-move-tp5803603p5803680.html Sent from the Mkgmap Development mailing list archive at

Re: [mkgmap-dev] Commit: r3200: Reapply 3198 as svn move

FYI: version 3194 produces the same garbled display. -- View this message in context: http://gis.19327.n5.nabble.com/Commit-r3200-Reapply-3198-as-svn-move-tp5803603p5803687.html Sent from the Mkgmap Development mailing list archive at Nabble.com. ___

Re: [mkgmap-dev] [patch v1] route restrictions

Got this one with a Germany extract from Europe: SCHWERWIEGEND (RoadNetwork): 66923004.o5m: Turn restriction (no_u_turn) http://www.openstreetmap.org/browse/relation/3598267 (at http://www.openstreetmap.org/?mlat=51.554189mlon=6.982870zoom=17) can't locate arc from 'via' node at

Re: [mkgmap-dev] [patch v1] route restrictions

GerdP wrote Hi Uli, please post a link to the input file 66923004.o5m Gerd Hi Gerd, there were no more messages and here is the input file: http://files.mkgmap.org.uk/download/199/66923004.o5m Regards, Uli -- View this message in context:

Re: [mkgmap-dev] [Patch v2] route restrictions

This version runs smoothly with the Germany extract - thanks! -- View this message in context: http://gis.19327.n5.nabble.com/Patch-v2-route-restrictions-tp5803296p5803316.html Sent from the Mkgmap Development mailing list archive at Nabble.com. ___

Re: [mkgmap-dev] Commit: r3176: add copyright info, no functional change

Unfortunately i get loads of node missing exceptions with the latest build. No problem with version 3169. Will try to run again with saving to log and post output here. -- View this message in context:

Re: [mkgmap-dev] Commit: r3176: add copyright info, no functional change

GerdP wrote Hi Uli, please make sure to use latest splitter (r321) so that all supported restriction relations are complete. Gerd Hi Gerd, i alread use splitter r321 since it came out. Do i need to change options for splitter to keep restriction relations complete? Regards, Uli --

Re: [mkgmap-dev] Commit: r3176: add copyright info, no functional change

Here is a sample from the output: - SCHWERWIEGEND (RestrictionRelation): 66923006.o5m: Turn restriction (only_straig ht_on) http://www.openstreetmap.org/browse/relation/2906958 (at http://www.opens

Re: [mkgmap-dev] bounds and sea on pleiades

ligfietser wrote Lambertus, Is the latest bounds file correct? It is much smaller (72 Mb) than the previous ones (412 Mb) I would like to second this question and therefore push it up again. -- View this message in context:

Re: [mkgmap-dev] Commit: r2520: Handle trunks with the process-exit option

GerdP wrote Hi Uli, yes, splitter r295 required Java 1.7 without intention.This is fixed again with r296. mkgmap r2520 compiles fine on 1.6, but the unit tests fail because of the message regarding the switch to 1.7 Gerd Hi Gerd, thank you for the information! Then i think it's best,

Re: [mkgmap-dev] Commit: r2520: Handle trunks with the process-exit option

Hmm, there is no download for the new versions of mkgmap and the splitter? :? -- View this message in context: http://gis.19327.n5.nabble.com/Commit-r2520-Handle-trunks-with-the-process-exit-option-tp5752351p5752355.html Sent from the Mkgmap Development mailing list archive at Nabble.com.

Re: [mkgmap-dev] splitter r288 ready for trunk?

Have been using splitter 288 on daily basis since you published it without any complications, so no interventions from here! ;) -- View this message in context: http://gis.19327.n5.nabble.com/splitter-r288-ready-for-trunk-tp5749465p5749593.html Sent from the Mkgmap Development mailing list

Re: [mkgmap-dev] Commit: r2461: Merge the mkgmap_exits branch

Hello again, yes it worked, at least partly. ;) When going from A391 to A2 it only says: Nach Osten auf A2 but when going from A2 to A39 it says: Rechts auf A39 abbiegen (Salzwedel,Wolfsburg) - That is new! :) Thanks again and kind regards, Uli -- View this message in context:

Re: [mkgmap-dev] Commit: r2461: Merge the mkgmap_exits branch

Hello WanMil, i get a simple A391 nach A2 message and then at the junction i get rechts auf A2 abbiegen. I expected something like rechts auf A2 Richtung Berlin abbiegen? Here is my lines file: lines http://gis.19327.n5.nabble.com/file/n5746640/lines Regards, Uli -- View this message in

Re: [mkgmap-dev] Commit: r2461: Merge the mkgmap_exits branch

Thanks a lot, i'll try at once and will see tomorrow, if it works. If i use the --process-destination option, do i have to add another command to the lines file? Regards, Uli -- View this message in context:

Re: [mkgmap-dev] Commit: r2461: Merge the mkgmap_exits branch

Again: Thanks a lot! The new gmapsupp.img, that starts being computed this night @1:10am will be made with the new settings. I will report tomorrow! Thanks again and king regards, Uli -- View this message in context:

Re: [mkgmap-dev] Commit: r2461: Merge the mkgmap_exits branch

Hello, i activated the new option and changed the lines file according to the lines file in the default style. The generated gmapsupp.img is slightly bigger than the normal one. Unfortunately i don't see any difference in routing hints? Do i have to activate some switches in my navigator? I use

Re: [mkgmap-dev] splitter and multiple files

The --keep-complete option is now the default. Have you tried --keep-complete=false ? -- View this message in context: http://gis.19327.n5.nabble.com/splitter-and-multiple-files-tp5745405p5745412.html Sent from the Mkgmap Development mailing list archive at Nabble.com.

Re: [mkgmap-dev] Commit: r2412: merge the o5m-support branch

GerdP wrote Hello Uli, writing o5m may require more heap compared to pbf. Please make sure that splitter did not crash. If you have the splitter log(s), please make sure that you find something like Time finished: Mon Dec 17 18:53:48 CET 2012 Total time taken: 1463s in the last

Re: [mkgmap-dev] Commit: r2412: merge the o5m-support branch

Hi there, in a few minutes the two runs with o5m and pbf will finish. Are these logs still needed? Beside the different timestamps the logs seem to be identical so far. Kind regards, Uli -- View this message in context:

Re: [mkgmap-dev] Commit: r2412: merge the o5m-support branch

Meanwhile the process finished and yes, a lot of water, lakes, rivers and streams are missing in the finale IMG created from o5m. Here the corresponding logs: logs.7z http://gis.19327.n5.nabble.com/file/n5740834/logs.7z -- View this message in context:

Re: [mkgmap-dev] Commit: r2412: merge the o5m-support branch

GerdP wrote Ok, Bad luck while testing : I just took tile 63240001 to compare, and all errors disappeared with r2414. I've now verified all 34 tiles. Please try r2415. Gerd I would like to test immediately, unfortunately i'm at work behind a firewall 1 and therefor i can't access the

Re: [mkgmap-dev] Commit: r2412: merge the o5m-support branch

Hello there, first i want to say great work with the new versions of splitter and mkgmap! In the moment i'm using mkgmap r2412 in conjunction with splitter r263 and encounter a problem: Formerly i used the following tool chain: 1) data.pbf - splitter - tiles.pbf - mkgmap - gmapsupp.img

Re: [mkgmap-dev] new tile splitter released: r263

Hello everyone, i have a little problem using latest mkgmap r2412 with splitter r263 and --output=o5m. Please see full description here: http://gis.19327.n5.nabble.com/Commit-r2412-merge-the-o5m-support-branch-td5740691.html Kind regards, Uli -- View this message in context:

Re: [mkgmap-dev] splitter r246

WanMil wrote Hi Uli, the reason for the error is the new split algorithm introduced with splitter r245 and r246. But the split algorithm is *not* defective. It's more an unfortunate combination of circumstances. The new split algorithm created the tile 66923055 which covers most of

Re: [mkgmap-dev] splitter r246

Uli, can you please retry and give the exact error message of mkgmap? I guess that one of your tile contains a large polygon that is now contained completely in the tile due to keep-complete. Maybe a part of mkgmap has a problem with this large polygon (e.g. subdivision handling). But this

Re: [mkgmap-dev] splitter r246

I've uploaded the defective tile 66923055.osm.pbf. mkgmap takes a lot more time with this tile. I start 3 threads and mkgmap is already at a tile number wide above 100 when the message for tile #55 is displayed. ___ mkgmap-dev mailing list

[mkgmap-dev] splitter improvements

Hi Gerd, this is the way i create the germany + 50km + iceland .osm.pbf-file: First step is download from geofabrik (only about once a month): ..\bin\wget --no-cache http://download.geofabrik.de/openstreetmap/europe.osm.pbf Then i cut the interesting area(s), i'll attach the corresponding

[mkgmap-dev] splitter improvements

Hi Gerd, i just tried it once again using splitter-r231. This is the error, that occurs: 23.000.000 ways processed... id=175802045 24.000.000 ways processed... id=184296766 Stats for MultiTileProcessor pass 2 endMap Pass2 end SparseBitSet problemRels 173576 (917000 bytes) SparseBitSet

[mkgmap-dev] splitter improvements

Hi Uli, I fixed the error with r232 which I've just committed. Thanks for reporting ! Gerd Hi Gerd, you're welcome! :) Only minutes ago splitter-r232 just flew thru the germany+ dataset on a 32-bit-environment using -Xmx1376m without a single problem! The problem-candidates-list sizes

[mkgmap-dev] splitter improvements

I think the memory requirements are more dependent on the data than on the splitter version: I have a self created data set consisting of germany + ~50 kilometers plus the data from iceland cut with osmconvert.exe from the europe.osm.pbf from geofabrik, which is processed without errors with

[mkgmap-dev] splitter improvements

Hi, I want to reproduce the problem, but I don't see a file with 1.9GB at this place: http://140.78.94.22/osm/ Where am I wrong? Gerd Just saw, my email program messed up the format, so here once more in better readable form: Hi Gerd, sorry, i forgot to mention: I take the germany+.osm.xz