[mkgmap-dev] [PATCH v3] make DP filter avoid removing points located at nodes

v3 - hopefully, now works again after being broken by the round coords filter. - v2 - based on r1402. --- Hi Felix, Please try the attached patch. I've tested it inasmuch that it doesn't blow up but whether it actually does the right thing when you have a routable and non-rout

Re: [mkgmap-dev] weird: file missing when # of files > 10?

> Hi Valentijn, Having looked at the code more, I realise that my initial thoughts were not right so I am back to the "stumped" state (i.e. I don't know what the problem is). Please tell me, what Java runtime/compiler are you using? Does the behaviour change if you use a different runtime? Cheer

Re: [mkgmap-dev] weird: file missing when # of files > 10?

> Would it help you if I sent you the patch from the mapset branch that > changes this behaviour? (Would save you from resurrecting a deleted branch). No thanks, I have all of the branches. > > Please tell me, what Java runtime/compiler are you > > using? Does the behaviour change if you use a

[mkgmap-dev] [PATCH v4] make DP filter avoid removing points located at nodes

v4 - err, try again - v3 - hopefully, now works again after being broken by the round coords filter. - v2 - based on r1402. --- Hi Felix, Please try the attached patch. I've tested it inasmuch that it doesn't blow up but whether it actually does the right thing when

Re: [mkgmap-dev] weird: file missing when # of files > 10?

> And... it fixes the problem. I ran a full build and it seems to be OK. Glad to hear it. > Now I'm still stumped though - I think now Sun (Oracle?) is the only one > who can fix that? ;) It's a weird problem, if I had all the time in the world I would have a trawl through the release notes an

Re: [mkgmap-dev] [PATCH v4] make DP filter avoid removing points located at nodes

Hi Felix, > finally works again. thanks. Great, sorry for the hassle. If you are happy with how this is working, I could commit this. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/

Re: [mkgmap-dev] [Ghost road]

Hi Steph, > Thx for your reply Mark, > The road doesn't appear in the .osm file, only in the .img. So I don't > have everything more on it. Yes, you do, tell us where it is. What are the OSM coodinates (permalink, OSM URL, whatever you care to call it.) > Here are my command line : > java -j

Re: [mkgmap-dev] [PATCH v4] make DP filter avoid removing points located at nodes

Felix, > Yeah, I'm happy about it. Don't you want to commit the > multiple_elements_patch at the same time? > It's working great for me and many others since a long time. Never > noticed any bad effect (well only that it could be even better by also > allowing to put multiple oneways contraflo

[mkgmap-dev] [PATCH v1] remove bogus nodes

With the recent reversion of the Table A breakage, it's now useful to post this patch for wider testing as it no longer causes my Nuvi to barf. What it does is remove routing nodes from ways that should never have been put there in the first place. Without this patch, a routable way will have a n

Re: [mkgmap-dev] [PATCH v1] remove bogus nodes

Hi Felix, > Just trying it out. I'm allways eager to see routing improvemtns. > However can't get my maps to compile: > > java.lang.AssertionError: Point in way Achenseeschiffahrt ferry > (http://www.openstreetmap.org/browse/way/35958231) has zero highway > count at http://www.openstreetmap.o

Re: [mkgmap-dev] [PATCH v1] remove bogus nodes

Felix, > Here's the lines I had to comment out: > > # route1=ferry { name '${name1}'; set toll=yes } > [0x06 road_class=1 road_speed=0 resolution 18 continue] > # route=ferry { name '${name} ferry' | 'ferry'; set toll=yes } > [0x06 road_class=1 road_speed=0 resol

[mkgmap-dev] [PATCH v2] remove bogus nodes

v2 - avoid assertion when more than one routable way is generated from the same OSM way --- With the recent reversion of the Table A breakage, it's now useful to post this patch for wider testing as it no longer causes my Nuvi to barf. What it does is remove routing nodes from ways that sho

Re: [mkgmap-dev] [PATCH v1] remove bogus nodes

Hi Felix, thanks for the high quality feedback - new patch has been posted. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] [PATCH v1] remove bogus nodes

Hi Johann, Sorry for not replying sooner, I have been concentrating on fixing the bug that Felix unearthed. > in general i like this idea. Removing superfluos nodes also improves the > dp filter, as it can remove more nodes. I would be very pleased, if with > this patch it would be possible to

Re: [mkgmap-dev] [PATCH v1] remove bogus nodes

Hi Felix, What I don't understand is how the ferry route in your original bug report was generating multiple routable ways. It's not tagged as being a cycleway. I guess that your style rules must have matched it twice and both times set the road class or speed. Mark _

Re: [mkgmap-dev] [PATCH v1] remove bogus nodes

Felix, Another thought: The current code will probably not work as expected if you generate any lines (most likely routable lines, but could also be long non-routable line) that are split and you then go on to generate more lines (routable or not) from the same way. The problem is that once the

[mkgmap-dev] [PATCH v3] remove bogus nodes

v3 - now duplicates ways so that any structural changes to the way made while processing a line/road will not affect the original way and so each map object generated from the original way will see the full set of points in the way. Duplicating the ways appeared to have no noticeable effect on th

Re: [mkgmap-dev] [PATCH v3] remove bogus nodes

Hi Marko, Thanks for the report. > On Sat, Nov 28, 2009 at 02:03:14PM +0000, Mark Burton wrote: > > v3 - now duplicates ways so that any structural changes to the way made > > while processing a line/road will not affect the original way and so > > each map object genera

[mkgmap-dev] Simplifying ways

Hi Felix (cc Johann) > Just as a follow up, I noticed that the v8 patch (simplify ...) - > actually routing over long distances in Mapsource became worse. Some > routes I can calculate without using this patch, don't calculate with > the patch anymore. You posted this comment with a subject l

Re: [mkgmap-dev] Simplifying ways

Hi Felix, > No Johanns (v8) patch actually improves long distance routing (2-3 > additional turns), while the remove bogus roads makes long distance > routing worse for me (3-4 turns less). Sorry for the wrong text. OK, thanks for clarifying that. My comments in the last message can therefor

Re: [mkgmap-dev] Simplifying ways

Hi Johann, Thanks for taking the time to explain your patch. > Seems you missed the important fact, that the merging takes place only > at resolutions <=23. As far as I understand the whole thing, line data > at lower resolutions is used only for displaying. Yes, I missed that crucial point.

Re: [mkgmap-dev] Simplifying ways

Felix, > I don't know what's the difference between patch v3 and patch v2, but v3 > makes no practical improvement. Yes it sets the different speeds and > road_class for 0x01 and 0x02, but impossible to set different > restrictions, they are simply dropped. Having made a complete fool of myse

Re: [mkgmap-dev] Simplifying ways

> Standby... Attached, completely untested, probably destroy the universe... diff --git a/src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java b/src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java index abc8941..d314fd4 100644 --- a/src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java +

[mkgmap-dev] Simplifying ways & rounding

Hi Johann, Been trying your patch and it works well. Certainly doesn't seem to break the routing. However, it doesn't always merge ways that, as far as I can tell, should be merged. I have studied your code so I know how you're doing the matching. One thought, would rounding the coords before mer

Re: [mkgmap-dev] Simplifying ways & rounding

Hello again, > Been trying your patch and it works well. Certainly doesn't seem to > break the routing. However, it doesn't always merge ways that, as far > as I can tell, should be merged. I have studied your code so I know how > you're doing the matching. One thought, would rounding the coords

Re: [mkgmap-dev] Simplifying ways & rounding

Johann, > > > > I'm being so stupid today, it's the subdivisions. The lines that are > > not matching are in different subdivision so they don't get compared. > > > > > Thanks for the hint, this was it. I have noted that the lines are not > merged at subdivisions, but not thought to the final

Re: [mkgmap-dev] Simplifying ways

Felix, > not destroying anything, but also not helping. Restrictions are still > set by the first way (using continue) the second routable way > restrictions set via {} are not enacted. Oneway also not changed. Well, I tried an example like yours but could not get any sense out of it at all.

[mkgmap-dev] Don't let action rule execute its actions if its type isn't going to be used

Felix, As you know, action rules execute their actions (like add tags, etc.) whenever their expression is true. But is that the right behaviour if the type associated with the rule isn't going to be used because of the continue action? I'm not sure that it is so I have made a little patch that s

Re: [mkgmap-dev] Don't let action rule execute its actions if its type isn't going to be used

Hello Felix, > ... Ups too fast. if I use: > /highway=* & copy=99 { set oneway=no }[0x01 road_class=0 > road_speed=0 resolution 24 continue] > highway=* & copy=98 { set oneway=no }[0x01 road_class=0 road_speed=0 > resolution 24 continue] > highway=* & ( copy=99 | copy=98 ) [0x02 road_cl

Re: [mkgmap-dev] Don't let action rule execute its actions if its type isn't going to be used

Felix, Please try this new patch to trunk. Don't use any other of my recent style patches as it contains all the current stuff. This now suppresses action execution when looking for further matches. If you want the actions to be executed anyway, add 'with_actions' (or 'withactions', both are rec

Re: [mkgmap-dev] Simplifying ways & rounding

Johann, > The merge lines patch is designed from start for high line numbers. It > uses internal hashlists for performance reasons. I would expect the > runtime to raise n*log(n), not n². So I do not expect it to burn cpu, > but would need a test to proove it. OK. > But I'm not sure, if merg

Re: [mkgmap-dev] [PATCH v1] Improve delete-tag-list with blacklist-tags-file and whitelist-tags-file

Hi WanMil, Sorry, your patch has not yet been discussed. We have been very busy recently. It has not been forgotten. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Don't let action rule execute its actions if its type isn't going to be used

Hi Felix, Thanks for the report. > Overall: Great it's the first time the patch actually seems to work as > expected (as expected when looking at the result with gpsmapedit). > Inside Mapsource it works 100% when not starting or ending on the street > that is oneway. So if you have to route over

Re: [mkgmap-dev] Don't let action rule execute its actions if its type isn't going to be used

Hi Clinton, > Thanks, but what I was having trouble understanding is the stopping of > actions when the type isn't going to be used. That is, where would > 'with_actions' be necessary, and what is the consequence of not having this > set? The problem was that the actions, e.g. { set foo='bah'

[mkgmap-dev] [PATCH v4] remove bogus nodes

v4 - added --remove-bogus-nodes option to turn on this feature. Even though the reduction in nodes is fairly modest (typically 5-10%), I believe that this could be useful for those routable ways that share many points with non-routable lines or areas. A lot of roads do share points with neighbour

Re: [mkgmap-dev] Commit: r1410: Add --merge-lines option to combine lines at lower zoom levels.

Felix, Johann, > > Okay, the merge-lines seems to be responsible for it! - However also > > very aggressive dp filter settings might cause the tooltip to show up > > slighltly away from the mouse (the tooltip will show up where the road > > would be in resolution 24) - however only when using

Re: [mkgmap-dev] Turn Restrictions

Hi Rodrigo, > I'm having some problems with turn restrictions in Garmin Mobile XT. > > Take a look at this roundabout: > OSM: http://osm.org/go/M5t4FIy73-- > Satellite: https://dl.dropbox.com/u/114881/screenshots/round-1.png > > In OSM data we have some turn restrictions. But when I convert the

Re: [mkgmap-dev] Commit: r1410: Add --merge-lines option to combine lines at lower zoom levels.

Hi Johann, > Hi Mark, > > if your guess is true (it indeed seems so), then this would mean that > there is some linking between the graphical line and the arc. I know > there is a one to one link at highest resolution. There seems to be link > at lower resolutions too. > > This may well be t

Re: [mkgmap-dev] Suggestion: set mkgmap:dead-end-check=no when endpoints have FIXME=*

Hi Marko, > I came across an incompletely mapped area that has some dead-end oneways, > and mkgmap duly complained. Initially, I "fixed" this with a bogus road > that had a FIXME tag, but the original mapper reverted that change. > Now I have added fixme=continue to each bogus oneway. I wanted

Re: [mkgmap-dev] Routing issue in Hameln

Hi Chris, > In german city Hameln turn-restrictions are used like hell, > but they don't seem to work. > > > > On the left side the only_straight_on restriction is not applied, > on the right side there is a "funny" routing. I

Re: [mkgmap-dev] Routing issue in Hameln

Hi Chris, > In german city Hameln turn-restrictions are used like hell, > but they don't seem to work. Err, yes. I broke them. Fixed now in 1414. Apologies to all. Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.

Re: [mkgmap-dev] Routing issue in Hameln

Hi Chris, > don't works for me. > > Still MapSource routes me directly to Koppenstraße or > Hunoldstraße coming from B1 left. > > v1414 (latest) > > my command line: > > java -Xmx1200m -ea -esa -jar ..\mkgmap\mkgmap.jar --latin1 > --description=test --country-name=DE --country-abbr=DE --famil

Re: [mkgmap-dev] routing oddity

Hi Valentijn, > A routing oddity on Mapsource and my Garmin Nuvi: > http://osm.org/go/0E6U9XKEb-?layers=0B00FTF > > When I'm driving on the A1 highway, it always sends me down the > motorway_link, then up on the motorway_llink again. Could this be > because the bridge over the Weteringweg makes

Re: [mkgmap-dev] Routing issue in Hameln

Hi Chris, > And now the reason for my map not using the TRs : > > the missing "--ignore-osm-bounds" ! > > So, if I understand correctly : > > when compiling data that comes out of splitter > --ignore-osm-bounds should not be used, but when > compiling small areas (from XAPI or stored from > J

Re: [mkgmap-dev] Commit: r1415: Set mkgmap:dead-end-check=false when end points have FIXME=*

Hi Marko, Sorry, for breaking your patch, your fix now committed. > A corrected patch is attached. The patch also adds some initialization > to addWay(), for additional safety against parsing errors or such. > My apologies for the line splits or indentation; I am not sure which > tab stop size

[mkgmap-dev] Your website makes my pc tired

Please forward this to your website design team. Many of the flash graphics on your webpages use a lot of CPU power on my PC. Could you please provide an option to disable the flash graphics or find some other way to stop them being such CPU hogs. For example, at the moment, your flash graphic "

Re: [mkgmap-dev] Your website makes my pc tired

Oh shit, how did that happen? ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] [PATCH v1] grok unpavedness

Bloody typical, you wait around for ages hoping for a new routing capability to be added to mkgmap and then two come along on the same day. I've been trying to discover how unpavedness is encoded for at least 6 months. Every now and again, I return to think about it some more. Check and re-check

[mkgmap-dev] [PATCH v2] grok unpavedness

v2 - sans syntax error - Bloody typical, you wait around for ages hoping for a new routing capability to be added to mkgmap and then two come along on the same day. I've been trying to discover how unpavedness is encoded for at least 6 months. Every now and again, I return to think abou

Re: [mkgmap-dev] [PATCH v1] grok unpavedness

> >> Not sure if those are the best tags to use - any thoughts? > >> > > I think the most used tag is surface=unpaved, but as usual > > we can do this in the style file. > > > > highway=*& (surface=unpaved | surface=dirt | surface=sand | > > surface=ground | surface=gravel) {add unpaved=yes

[mkgmap-dev] [PATCH v2] grok unpavedness + ferry nature

v3 - turns out they handle ferry routes in a similar fashion as to unpaved roads so I've added support for avoiding them (when route=ferry tag is present) - untested here due to paucity of ferries in Cheshire but I have verified that the unpaved stuff still works. - v2 - sans syntax erro

Re: [mkgmap-dev] [PATCH v2] grok unpavedness + ferry nature

Subject is wrong, should say v3 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] [PATCH v1] grok unpavedness

Hello all, > congratulations to your success with the unpaved bit. Thanks Johann. > For the keyword I would use mkgamp:unpaved, as some others has suggested > too. In my opinion most if not all tags used by mkgmap should start with > this prefix and should be translated in the style file. I

Re: [mkgmap-dev] Support for advanced multipolygons?

Hi Nop, > Are there any plans to support advanced multipolygons in mkgmap? Sorry, I can only give you a negative reply in that I know that I won't be signing up for working on that. Still, all contributions are welcome, if you can program, why not have a go at it yourself? Cheers, Mark _

Re: [mkgmap-dev] [PATCH v1] grok unpavedness

Hi Felix, > Yes works splendidly. No matter what 0x* type one chooses. Very good, I will commit it later this evening. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Suggestions

Hello Peter & Suzie > 1. The first suggestion I have is to output the warning messages in > html format so that when the url for a problem is logged, the file can > be opened in a browser and just click on the link to problem. > I played with this and it seems to work, maybe an extra option could

Re: [mkgmap-dev] [mkgmap-svn] Commit: r1419: Added support for "carpool lanes".

On Tue, 08 Dec 2009 23:54:15 + Steve Ratcliffe wrote: > On 07/12/09 15:53, svn commit wrote: > > Version 1419 was commited by markb on 2009-12-07 15:53:31 + (Mon, 07 > > Dec 2009) > > > > Added support for "carpool lanes". > > I believe that this change breaks setting access codes in MP

Re: [mkgmap-dev] [PATCH v1] grok unpavedness

Hi Steve, On Wed, 09 Dec 2009 10:27:33 + Steve Hosgood wrote: > Mark Burton wrote: > > Hello all, > > > > > >> congratulations to your success with the unpaved bit. > >> > > > > Thanks Johann. > > > > > >>

Re: [mkgmap-dev] Commit: r1426: Revert back to using Properties rather than EnhancedProperties.

Hi Valentijn, > Works now :) Good, sorry about that. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] [PATCH v1] grok unpavedness

Hello team, On Wed, 9 Dec 2009 14:04:34 +0200 Marko Mäkelä wrote: > Hi Valentijn, Steve, Felix, all, > > On Wed, Dec 09, 2009 at 12:57:34PM +0100, Valentijn Sessink wrote: > > Hi, > > > > I'm not sure I understand the mkgmap:tag stuff after all. > > > > The "mkgmap:ferry" is an internal mkgm

[mkgmap-dev] Address search in mapsource fails to find some streets

Just playing around with mapsource using the street search feature and noticed that some streets don't show up in the search. For example, in the GB map, I can select "Well Street" from the select street dialog but when I ask it to find that street, it says nothing found. Other streets in the same

Re: [mkgmap-dev] Motorway exits and link-pois-to-ways

Sorry chaps, should now be fixed. Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Commit: r1419: Added support for "carpool lanes".

Hi Johann, > > Any way can now be flagged as a "carpool lane" by giving it a > > carpool tag (e.g. carpool=yes). > > Shouldn't the tag be named 'mkgmap:carpool', accordingly to the other > newly inroduced tags? Already done (r1432). Cheers, Mark __

Re: [mkgmap-dev] State Highway 57 is broken!

Hi Simon, > Error message below, have fun. It was a blast, please try r1435. Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] State Highway 57 is broken!

Simon, > Thank you. I can confirm that it is not dying anymore but only shows an > Assertion Error (below, should it be interesting). Please try r1436. Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/l

Re: [mkgmap-dev] New (?) error message

Hello Nop, > Can anybody tell me the meaning of this error? I know some diagnostic messages are obscure but this one is telling you plain and simple that it is unwilling to split a particular area because it thinks it has become too small. Actually, I just checked the area it mentions and ther

[mkgmap-dev] Inserting hex codes in labels

I would like to be able to insert hex chars into labels so I can stop parts (or all) of labels being displayed when zoomed out (as described in cgpsmapper doc). Is there anyway our style code can support that? I know it has some highway shields but how about the other codes? Cheers, Mark ___

Re: [mkgmap-dev] Inserting hex codes in labels

Hi Gert, > Hi Mark, > unfortunately this hex sign square is not visible in the mail list. > I have replaced it with HEXSIGN as marker. > > ex. > highway=* {name '${ref|highway-symbol:box:6:4}HEXSIGN${name}' | > '${ref|highway-symbol:box}' | '${name}'; add display_name = '${ref} > ${name}' } >

Re: [mkgmap-dev] contour map error

Hi Apollinaris, > Got 7 of these errors for US Region_01 (161 tiles). What is the best way > to resolve? img file is still created > - split into tiles > - split contour lines for minor, medium, major into different osm files? > - ignore, can't find any obvious problems in the map at this locatio

Re: [mkgmap-dev] contour map error

Hi, > error is gone and tiles is ok in qlandkarte. will run all failing tiles now Sorry, is that with the number reduced to 10? If so, I may as well commit that change. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://ww

Re: [mkgmap-dev] contour map error

Hi Charlie, > I get a different error with UK contour lines from SRTM data: > > SEVERE (Polyline): Problem writing line (class > uk.me.parabola.imgfmt.app.trergn.Polyline) of type 0x20 containing 2 > points and starting at > http://www.openstreetmap.org/?lat=51.41591&lon=-8.2&zoom=17 > SE

Re: [mkgmap-dev] contour map error

Hi Charlie, > >> error is gone and tiles is ok in qlandkarte. will run all failing tiles now > > > > Sorry, is that with the number reduced to 10? If so, I may as well > > commit that change. > > > > Cheers, > > > > Mark > No, I'm afraid I haven't got the wits to edit source code and recompile

Re: [mkgmap-dev] contour map error

Hi Apollinaris, > yes, all tiles processed with setting to 10 Thanks, I'll commit that change. Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] frig-roundabouts

Hi Charlie, > Is the --frig-roundabouts option still needed/useful or has its > functionality been subsumed into something else now? I haven't used it for a long time and I now use --adjust-turn-headings which kinda does a similar thing but is more general. Cheers, Mark __

Re: [mkgmap-dev] Routing Problem in Southern Minnesota

Hi Jeff, > I'm having an issue with routing in southern Minnesota along I-35 with > my Oregon 300 (firmware 3.40). If I pick two points along I-35, one > south of Albert Lea and the other north of Owatonna my Garmin wants to > route me over to US 218 instead of using I-35. The same route using

[mkgmap-dev] Multipolygons and disappearing coastlines

Hi team, I have been asked by the Open Sea Map people to help them generate some maps with marine objects and while working on that I have noticed that if a way is part of a multipolygon then all its tags get removed. This is unfortunate because (in the test map I am looking at around Keil) the c

Re: [mkgmap-dev] Multipolygons and disappearing coastlines

Hi Chris, > Mark Burton schrieb: > > > So, is putting the coastline into a multipolygon a reasonable OSM > > thing? > > A coastline is often also a boundary and boundaries are > multipolygons in OSM. > > > If so, should mkgmap be breaking the coastline b

Re: [mkgmap-dev] mkgmap dropping ways on multipolygon boundary "outer"

Festive greetings Felix, > Have a look here, wherever the boundaries use the same way as the ways, > the ways get dropped, even if not rendering the boundaries at all > (removing any reference to boundary from the style-file). > > Is this maybe a geofabrik error, or some error in mkgmap multip

Re: [mkgmap-dev] mkgmap dropping ways on multipolygon boundary "outer"

Felix, > Thanks for that patch... It does remove the bug, but all relations seem > to get dropped by using this patch too. So not an ideal solution -:) > > BTW before using this patch, relations like cycleroutes would even show > up when all ways were dropped due to multipolygon outer... OK -

Re: [mkgmap-dev] mkgmap dropping ways on multipolygon boundary "outer"

Hi Felix, > Yip, that patch works great. (using only this patch, without the earlier > patch; if I add earlier patch too I loose the relations again) Yes, it replaces the earlier patch. Good. I am tempted to commit this - does anyone think that preserving the original ways is a bad idea? If

[mkgmap-dev] Understanding the sea

Hi, I'm trying to understand how the --generate-sea stuff works. I want to know how it decides whether an "island" is water or land. The code does not really contain sufficient comments for me to work out what it's doing. I would expect it to close coastline segments that reach the tile boundary

Re: [mkgmap-dev] mkgmap dropping ways on multipolygon boundary "outer"

Hello Felix, > Is there a reason for not committing the patch? It is working great for > me and also Steve found it good It has some good aspects but it also (as I think Steve mentioned) has the downside of causing the sea polygon to be preserved so everything ends up sea colour. As the multipo

[mkgmap-dev] [PATCH v2] - provide alternative sea drawing mechanism

Firstly, I would like to thank everyone who responded to my "Understanding the sea" post. From those posts and my own study, I finally worked out what it does. And yes, it works pretty well inasmuch that it generates some useful polygons. The "sea sector" heuristic doesn't work for me so I have be

Re: [mkgmap-dev] [PATCH v1] - provide alternative sea drawing mechanism

Hello Charlie, > Hurrah! Does this also mean that, with suitable definition of the > polygon used for land, we can finally banish the "Garmin yellow" > background to history? Yes (and no). You can give the "land" polygon whatever colour you desire. However, at the moment, the patch doesn't g

Re: [mkgmap-dev] [PATCH v1] - provide alternative sea drawing mechanism

Hi Ralf, > My Nuvi 255T does show the white background using my topo map. My 255W ignores any colour change on the 0x4b polygon. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-

[mkgmap-dev] [PATCH v3] - provide alternative sea drawing mechanism

v3 - generate land poly even if tile doesn't contain any sea (when --generate-sea=no-mp is specified) so that GPS units that ignore the colour of the background poly (0x4b) don't the wrong background colour. - v2 - avoid generating sea poly when unclipped tile contains coastline but the

Re: [mkgmap-dev] Baltic map looking good

Hi Bennie, Thanks for the kind words. I attach the TYP file I am currently using. It's very simple, I think most people use more complicated files than that. I also attach the style files. They are fairly similar to the default files with a few tweaked values here and there. The seamark related

Re: [mkgmap-dev] [PATCH v3] - provide alternative sea drawing mechanism

Hi Manning, > Thanks! My archipelago is now OK. Great, can you post a sample picture? > In my style file I added this: > natural=land [0x27 resolution 10] > > in the typ file draw priority: > 0x32 = 1 > 0x27 = 2 > all others = 3 and up Very good - I did not know that 0x27 was land, it's not

Re: [mkgmap-dev] Baltic map looking good

Hi Charlie, > I see you've got lots of placeholder polygons in your TYP file. Do you > know what these are / what they do / why one might want to use them? If you use a TYP file, then you require either a polygon definition or a placeholder for every type of polygon that you want in the map. T

Re: [mkgmap-dev] [PATCH v1] - provide alternative sea drawing mechanism

> Have you tried setting the polygon 0x10d "Basemap coverage area > (background)" to white, too? Don't think I have, will try sometime. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/m

Re: [mkgmap-dev] Commit: r1449: Provide an alternative to using a multipolygon when generating the sea.

Hi Felix, > It worked in 12/13 tiles. See below the broken tile where no 0x10f1d > polygon for the sea (as defined in polygons file) got created at all, > furthermore 1 island is flooded (in the center of the tile). I used grey > as backround color so one can easily spot mistakes. >From my me

Re: [mkgmap-dev] Commit: r1449: Provide an alternative to using a multipolygon when generating the sea.

PS - try no-sea-sectors - e.g. --generate-sea=polygons,no-sea-sectors ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Commit: r1449: Provide an alternative to using a multipolygon when generating the sea.

Felix, > > PS - try no-sea-sectors - e.g. --generate-sea=polygons,no-sea-sectors > > > Well if I use that option then I get the whole tile flooded. As I said before: "If you don't clip the coast, expect toast!" > The good thing is, the --generate-sea option only adds about 7-8% of > gener

Re: [mkgmap-dev] Commit: r1449: Provide an alternative to using a multipolygon when generating the sea.

Felix, > Okay, so manual coastlines are probably still needed except for very > large extracts or islands. Don't know what you mean by "manual coastlines" - the whole map is "manual", isn't it? > BTW it would be better to have mkgmap=land or similar, instead of > natural=land because natural

Re: [mkgmap-dev] Multipolygons and basic question on polygons with holes

Hi Steve, > I've no idea, I've been wondering too. It could be that the way Mark is > doing the sea/island polygons is the right way, except that if I'm not > mistaken his method only works with a TYP file, whereas it is clearly > possible to do this without since the MetroEurope maps don't h

[mkgmap-dev] Snapshot of style rules for seamark points

I've just committed some Java support for seamark marine lights. If you want to create maps with seamark objects you also need some style rules in the points file. I append a snapshot of what I am currently using. At some future time, it could be merged into the default style or be in a special ma

[mkgmap-dev] Mapsource installer

I wish to make a mapsource installer for the Baltic map. Can anyone please provide a simple recipe for doing that? Thanks, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Mapsource installer

Hi Steve, Thanks for the quick response. > 2. Run mkgmap with the --nsis option. This will give you a .nsi file > (by default osmmap.nsi). This is just a text file that you can adjust > if need be. OK - I notice that it misses out the TYP file and indexing files. It would be good if it include

Re: [mkgmap-dev] Baltic map looking good

Charlie, > So why have a placeholder when you could just put in a polygon definition? Good question - the placeholder simply gives the polygon's draw priority, the style for that polygon will be whatever default the GPS/mapsource uses. When you provide a full definition, you specify the visual s

Re: [mkgmap-dev] Mapsource installer

Hi Nakor, > Mark, I am not familiar with TYP files, but if you provide me a sample > with all the files you submit to mkgmap, the command line and which > files should be included in the install I will be glad to improve the > NSIS file generation. If you give the --index option mkgmap generates

<    1   2   3   4   5   6   7   8   9   10   >