Re: [mkgmap-dev] natural=coastline;cliff
Patch works for UK. However I think we should rather have this done generally for ";". Here is the current behaviour of mkgmap when it comes to in my eyes incorrect, but for some people acceptable strange tagging: *a) Two times the same key (e.g. natural=coastline ; natural=forest):* I think this does not matter anymore. JOSM does not allow to use this. Just for reference. Current behavior is that on all objects with two times the same tag, the second tag is read, i.e. * * So in this case, motorway would be rendered. It I is switched over to: . then trunk would be rendered. *b) values divided by ";"* You can currently only get them by using a wildcard like shop=* or natural=*. I think either mkgmap should take the" ;" 1. as stop, and use the value up to ";" - except if value is "name" or "ref". This should not increase compile time at all if implemented well to my understanding, and at least the first (and usually major) value would be parsed. Maybe the same could be achieved by regex??? 2. use it to split up the value into two keys. So say out of highway=motorway;trunk make highway=motorway & highway=trunk. As in the motorway;trunk a proper style-file (like the default) would drop trunk (no "continue") used. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] multipolygons: how to flag role=inner role=outer in Style file?
Hi,
I've tried to put in the relation file:
type=multipolygon { apply role=inner { set inner=yes } }
And in the polygons file:
natural=water & inner=yes [0x27 resolution 14]
But it seems not doing anything.
Looks like the multipolygon processing is done before it reads the
relation style file?
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Commit: r1587: When checking for natural=coastline, cope with compound tag values.
Version 1587 was commited by markb on 2010-02-28 11:27:44 + (Sun, 28 Feb 2010) When checking for natural=coastline, cope with compound tag values. Don't be fooled when someone does: natural=coastline;foo We now grok the coastline and replace the tag with natural=foo. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] natural=coastline;cliff
Hi Felix, > Patch works for UK. Good, me too - I have committed it. > However I think we should rather have this done generally for ";". Quite possibly, but that requires more thought/effort and what we need right now is a quick fix to make the coastline work again so we will have to make do with my effort for the moment. When a better solution comes along, we can take out this code and it will have served its purpose. Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] bug in road-name-pois
Hi, The option --road-name-pois often creates place names that are totally wrong. Two adjacent streets in the same district can have different place names. I think it is better not to show the place name until this problem is solved? Is there a way to make these POI invisible on the map? ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] bug in road-name-pois
Hello Minko, > The option --road-name-pois often creates place names that are totally wrong. > Two adjacent streets in the same district can have different place names. > I think it is better not to show the place name until this problem is solved? > Is there a way to make these POI invisible on the map? The maker of the map can use any POI type code and some show as blobs on the map and some do not. It also depends on which GPS model you are using. If the place names are unreliable, it would be better not to use the road-name-pois option. It should be redundant now anyway if the roadname search works OK. I originally implemented the road-name-pois option as a workaround for the lack of road searching capability. Other people worked on the location code that decides the place names - it sounds like it's that code that's being odd, not the road-name-poi feature, itself. Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] bug in road-name-pois
Hi Mark, I tested the address search now on my etrex, and yes it works fine without the road-name-pois. I also tested my map on a Garmin Nuvi, but on this unit it asks 'In what State/Prov is the Address?' and then it can't find anything. Perhaps I forgot something in the mkgmap options (I didnt use --region-name)? Btw my custom map files & styles can be found at http://sites.google.com/site/openfietsmap/ Mark Burton wrote: It should be redundant now anyway if the roadname search works OK. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] problems with POI names
Moin,
I have a problem with POIs, which have an ref-tag (using mkgmap-r1586).
First of all, if the POI does not have a name, then the ref-tag is displayed in
the map. In my lines file, I have specially a rule for adding the ref-tag to the
name, so I am a little bit surprised, that this is happening for the POIs
automatically.
Are there some other tags wich will be used instead of the name tag?
My second problem is, that I wanted to delete the reference, by adding this
action part to my style rule: {set ref=""}
As a result, all POIs where I wanted to delete the reference, now get their name
from a totally unrelated POI.
Gruss
Torsten
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Garmin colour palette
Daniela Duerbeck wrote: > Hi! > > I am not sure whether this is the correct ML for this posting, but I > think it is not completely wrong. > I saw that the colour palette used in the online Typ file editor has too > few and some wrong colours, almost for my Garmin Etrex Legend HCx. > > So I extracted the colour palette of a Garmin waypoint icon and built a > webpage that shows the correct colours (at least for my L:egend, I don't > know whether it is the same for other Garmins with 265 colours, but I > think so): > http://www.deltadelta.de/garmin_colours/ > > You can also download all the pages for offline use: > http://www.deltadelta.de/garmin_colours/garmin_colours.zip > > When you click on one colour you get a page completely coloured in this > colour with the hex representation for better cutting and pasting it > into the editor. > And also because a colour can better be judged when a big area is > coloured. (A wall painted looks always different from the small sample > in the shop ...) > > Perhaps someone will find it useful. > > Dani > Dani, Thanks for making this - very useful. Have a look here too for more on Garmin colour palettes and optimising your TYP file to match: http://clic0.free.fr/spip.php?article28 (in French) -- Charlie ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v2] - yet more turn heading adjustment fixes
Mark Burton escribió: > v2 - further fixes > > Carlos, this still gives you an extra "turn left onto Calle Osa > Mayor" and I know what's happening there but can't fix it Will it break other things? > - how > about the other problems you were seeing? better/worse? > Better, "keep right at Avenida de las Delicias" has changed to "turn right..." (step 3 of my explanation). Turn right at 4 is still happening. > > > Hopefully, these changes will fix the bad routing directions we have > been seeing recently - please test and report success/failure. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v2] - yet more turn heading adjustment fixes
Hi Carlos, > > Carlos, this still gives you an extra "turn left onto Calle Osa > > Mayor" and I know what's happening there but can't fix it > Will it break other things? It's a problem - if I change it so that it doesn't give you that extra turn left, then when the route is reversed, it won't tell you to turn right from Calle Osa Mayor (rather than continue on round the left bend). So is it worse to have the turn left direction when, in fact, the road carries straight on, or is it worse for the turn right direction to be missing when coming the other way? Actually, I don't yet totally understand why the turn left is happening so it could possibly be that I can make it do the correct thing when routing in either direction. More work required.. > > - how > > about the other problems you were seeing? better/worse? > > > Better, "keep right at Avenida de las Delicias" has changed to "turn > right..." (step 3 of my explanation). Turn right at 4 is still happening. > > Well, better is better (if not perfect)! Given that it was broken, I think I should commit some/all of this patch so that at least it's less broken than it was. Thanks for the feedback. Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v2] - yet more turn heading adjustment fixes
Mark Burton escribió: > Hi Carlos, > > >>> Carlos, this still gives you an extra "turn left onto Calle Osa >>> Mayor" and I know what's happening there but can't fix it >>> >> Will it break other things? >> > > It's a problem - if I change it so that it doesn't give you that extra > turn left, then when the route is reversed, it won't tell you to turn > right from Calle Osa Mayor (rather than continue on round the left > bend). So is it worse to have the turn left direction when, in fact, > the road carries straight on, or is it worse for the turn right > direction to be missing when coming the other way? > Calle Osa Mayor is oneway, so no reverse route is possible. > Actually, I don't yet totally understand why the turn left is happening > so it could possibly be that I can make it do the correct thing when > routing in either direction. More work required.. > > >>> - how >>> about the other problems you were seeing? better/worse? >>> >>> >> Better, "keep right at Avenida de las Delicias" has changed to "turn >> right..." (step 3 of my explanation). Turn right at 4 is still happening. >> >>> >>> > > Well, better is better (if not perfect)! > > Given that it was broken, I think I should commit some/all of this > patch so that at least it's less broken than it was. > > Thanks for the feedback. > Yes, I also think some improvement is better than nothing. I wonder if nobody else have seen these kind of anomalous turn instructions. More cases could help guessing what is happening. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v2] - yet more turn heading adjustment fixes
Hi Carlos, > Calle Osa Mayor is oneway, so no reverse route is possible. Some of it is oneway, the part I am talking about is not oneway. Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Commit: r1588: Fix test of whether a side road is to the left or the right of the main road.
Version 1588 was commited by markb on 2010-02-28 22:22:50 + (Sun, 28 Feb 2010) Fix test of whether a side road is to the left or the right of the main road. This was failing when the side road was more than 180 degrees different from the outgoing heading (that could occur when the main road bent at the junction and the side road is almost pointing back to where the incoming road came from). ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Commit: r1589: Be more discerning when matching arcs by class/speed.
Version 1589 was commited by markb on 2010-02-28 22:22:54 + (Sun, 28 Feb 2010) Be more discerning when matching arcs by class/speed. When matching an incoming arc to an outgoing arc by dint of the fact that they have the same class/speed, take care to avoid using an outgoing arc that has the same name/ref as another arc because they are probably the same road. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Commit: r1590: Avoid adjusting the heading of an arc previously used as an outgoing arc.
Version 1590 was commited by markb on 2010-02-28 22:22:57 + (Sun, 28 Feb 2010) Avoid adjusting the heading of an arc previously used as an outgoing arc. Now, if an arc is used as an outgoing arc, don't let its heading be changed when processing a later incoming arc. This requires that the incoming arcs are processed in decreasing order of class/speed so that the "bigger" roads are matched first. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Commit: r1591: Add inRoadDef local to reduce number of calls to getRoadDef().
Version 1591 was commited by markb on 2010-02-28 22:23:01 + (Sun, 28 Feb 2010) Add inRoadDef local to reduce number of calls to getRoadDef(). ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Commit: r1592: Now possiblySameRoad() returns true if the arcs have the same RoadDef id.
Version 1592 was commited by markb on 2010-02-28 22:23:04 + (Sun, 28 Feb 2010) Now possiblySameRoad() returns true if the arcs have the same RoadDef id. Rather obvious but somehow it got left out. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Commit: r1593: Disabled matching arcs by class/speed - more work required.
Version 1593 was commited by markb on 2010-02-28 22:23:07 + (Sun, 28 Feb 2010) Disabled matching arcs by class/speed - more work required. It's not obvious that this is a good idea so turn it off for the moment. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v2] - yet more turn heading adjustment fixes
Mark Burton escribió: > Hi Carlos, > > >> Calle Osa Mayor is oneway, so no reverse route is possible. >> > > Some of it is oneway, the part I am talking about is not oneway. > It seems you know my city better than me ;-) . It's not tagged as oneway, but it is a de facto oneway, as it connects with two oneway streets pointing in the opposite direction. Anyway, it's a bit estrange, so I'll try to check it on the place tomorrow. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v2] - yet more turn heading adjustment fixes
Carlos, > It seems you know my city better than me ;-) I wish I did, I'm sure the weather would be a lot nicer there than it is here! The closest I have been to your city is looking at it with josm. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
