November 2024 - mkgmap-dev - The mkgmap lists

Re: [mkgmap-dev] Internal Error Failed to render Multipolygon
by Ticker Berkin 24 Dec '24

24 Dec '24

Hi Thomas I've just loaded the relation 1754729 with JOSM. JOSM validation reports no errors, but mkgmap (direct, no splitting) gives errors: WARN: uk.me.parabola.imgfmt.app.Area lakeLadoga.osm: Area.split 2852864 1400832 2854912 1402880 res 11 can't 2 1 WARN: uk.me.parabola.mkgmap.reader.osm.MultiPolygonRelation lakeLadoga.osm: Multipolygon http://www.openstreetmap.org/relation/1754729 [ele=4.84, int_name=Ladoga lake, name:en=Lake Ladoga, name=Ладожское озеро, natural=water, type=multipolygon, water=lake] contains errors. WARN: uk.me.parabola.mkgmap.reader.osm.MultiPolygonRelation lakeLadoga.osm: Polygon 4611686018427403156(4P)(259078070[118P]) carries role inner but is not inside any other polygon. Potentially it does not belong to this multipolygon The area.split WARN happens when there are too many object (points/lines/polygons) in 1 resolution unit. The other error is as described. I notice that this relation was edited a couple of days ago so maybe someone is fixing or creating problems. I'll try again in a few days and investigate more deeply. Regards Ticker On Mon, 2024-09-02 at 19:44 +0200, Thomas Morgenstern wrote: > Hi Ticker, I found : osmium-tool and splitter works proper. I can the > splitted <12345678>.osm.pbf open and render in JOSM. JOSM shows the part of > the multipolygon 1754729, which is inside the boundary of the polygonfile for > splitter. I assume, mkgmap has the problem. But sorry, I am not a good > programmer and can not do deeper investigation or find a solution. If you > interested, I can give you my polygon and the <maptile-number>.osm.pbf. > > Thomas > > > Am 02.09.2024 um 15:04 schrieb Ticker Berkin: > > > > > > Hi Thomas > > > > I get similar problems just using > > > > https://download.geofabrik.de/europe/britain-and-ireland.html > > > > directly. The relations that cause the problem are not within the above > > combined > > territories but excluding them would required a much more complicated shape > > to > > define the download area. > > > > Ticker > > > > On Mon, 2024-09-02 at 12:42 +0200, Thomas Morgenstern wrote: > > > > > > > > Hi Ticker, i made further investigation. You are right.: the > > > MultiPolygonRelation 1754729 ('Ladoga sea') was cut by ectract Scandinavia > > > from europe-latest.osm.pbf using osmium-tool . > > > I am not sure, but means this, that osmium can not write a proper > > > ectract, > > > if such Relation must bee split ? > > > This means also, osmium has a bug ? I must check my osmium version... > > > regards Thomas > > > > > > > > > Am 02.09.2024 um 10:30 schrieb Ticker Berkin: > > > > > > > > > > > > > > > > > > > > > Hi Thomas > > > > > > > > It isn't related to AngleChecker. > > > > > > > > I notice that both these relations have been changed in the last couple > > > > of > > > > days > > > > so maybe they were faulty. > > > > > > > > The large one is on the boarder with Scandinavia and it is likely that > > > > the > > > > map > > > > extraction download only had part of it and this gives rise to this type > > > > of > > > > error. > > > > > > > > Regards > > > > Ticker > > > > > > > > On Mon, 2024-09-02 at 09:43 +0200, Thomas Morgenstern wrote: > > > > > > > > > > > > > > > > > > > > > > > Hello , I use mkgmap-4921 with patch from Ticker Berkin - > > > > > Angelchecker-V6. > > > > > With that i get in Scandinavia following error : Internal Error Failed > > > > > to > > > > > render MultiPolygonRelation 1754729 and 304507. Rel. 1754729 is > > > > > 'Ladoga'- > > > > > sea > > > > > with 5 226 Elements. Rel. 304507 is Multipolygon=water, 171 Elements. > > > > > I assume the error ist not specific to the patch...and more common.. > > > > > How to avoid this ? > > > > > > > > > > regards Thomas > > > > > > > > > > _______________________________________________ > > > > > mkgmap-dev mailing list > > > > > mkgmap-dev(a)lists.mkgmap.org.uk > > > > > https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > mkgmap-dev mailing list > > > > mkgmap-dev(a)lists.mkgmap.org.uk > > > > https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > > > > > > > > > > > > > > > > > > > > > > > > > >

2 7

Problem in AngleFixer?
by Gerd Petermann 15 Dec '24

15 Dec '24

Hi all, in a private email Thorsten Kukuk contacted me about wrong turn instructions a sharp angles. An example is the node https://www.osm.org/node/27550903 A route coming from South that follows the way https://www.osm.org/way/36138336 at this junction should NOT produce a turn instruction. A route that turns left SHOULD produce a turn instruction. With current mkgmap it's vice versa and thus not OK. I thnk the current code in AngleFixer.java is too agressive as it tries to enlarge the angles so that a compact format can be used to write the heading values of the arcs at the mentioned node. It does this by changing the heading values of both arcs with go to the north. @Ticker: The code was introduced with your arcHeading_v2.patch, but maybe it existed before. Can you explain why the constant AngleChecker.SHARP_DEGREES is set to 46° instead of maybe 22.5° ? Gerd

3 37

Dealing with JOSM exports
by Felix Herwegh 22 Nov '24

22 Nov '24

Hi, for some special application I'm parsing gpx-files to osm-files, identical to importing the .gpx into JOSM, convert them to datalayers and finally export to .osm. These files are then processed by splitter to .o5m. I'd like to add a timestamp to the .o5m using "osmconvert --timestamp" next. While that normally works for split-files based on OSM data, for the above files osmconvert allways throws 6 warnings like osmconvert Warning: wrong sequence at node -324213 osmconvert Warning: next object is node -324214 osmconvert Warning: wrong sequence at node -324214 osmconvert Warning: next object is node -324215 osmconvert Warning: wrong sequence at node -324215 osmconvert Warning: next object is node -324216 I guess, osmconvert is expecting ordered increasing positive IDs only. Iirc the decreasing negative IDs are correct here nevertheless, implemented long ago to indicate dealing with non OSM objects. mkgmap seems to work perfectly fine on such split-files. Did I miss any means to avoid these warnings and have the timestamp added other than converting the IDs to positive? Thanks //Felix

2 1