Re: [mkgmap-dev] cannot route when end node is at the tile edge
It's exactly this node. I will post the bounds later On Sat, Jul 18, 2009 at 2:21 PM, Mark Burton wrote: > > Hi Maning, > >> The road intersection "Daang Hari" is exactly at the edge of my tile >> (made with splitter) routing does not work. But when I created >> another mapset without the splitter, routing works. >> >> >> http://www.openstreetmap.org/?lat=14.413996&lon=121.01714&zoom=18&layers=B000FTF >> > > Which part of this junction actually falls on the exact line of the > edge? It can't be the whole junction, just some part of it. > > Can you please post the XML bounds elements from the two tiles? It's > near the top of the OSM file and looks like this example: > > maxlon='-0.131836'/> > > Cheers, > > Mark > ___ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > -- cheers, maning -- "Freedom is still the most radical idea of all" -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ -- ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] cannot route when end node is at the tile edge
Hi Maning, > The road intersection "Daang Hari" is exactly at the edge of my tile > (made with splitter) routing does not work. But when I created > another mapset without the splitter, routing works. > > > http://www.openstreetmap.org/?lat=14.413996&lon=121.01714&zoom=18&layers=B000FTF > Which part of this junction actually falls on the exact line of the edge? It can't be the whole junction, just some part of it. Can you please post the XML bounds elements from the two tiles? It's near the top of the OSM file and looks like this example: Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] cannot route when end node is at the tile edge
The road intersection "Daang Hari" is exactly at the edge of my tile (made with splitter) routing does not work. But when I created another mapset without the splitter, routing works. http://www.openstreetmap.org/?lat=14.413996&lon=121.01714&zoom=18&layers=B000FTF -- cheers, maning -- "Freedom is still the most radical idea of all" -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ -- ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [patch] change bus_stop to Transit Service category and add name / operator
used this in my
highway=bus_stop [0x2f17 resolution 21]
But it didn't appear in mapsource
On Fri, Jul 17, 2009 at 4:30 PM, Marko Mäkelä wrote:
> Hi Ben,
>
> On Fri, Jul 17, 2009 at 02:14:36AM -0400, Ben Konrath wrote:
>> Here's a patch to change the highway=bus_stop POI to the Transit Service
>> category and add the name and/or operator. As usual, comments are
>> welcome.
>
> Good idea! This will nicely separate bus stops and train stops. Maybe
> use the same symbol code also for tram stops?
>
>> -highway=bus_stop [0x2f08 resolution 21]
>> +highway=bus_stop { name '${name} - ${operator}' | '${name}' | '${operator}'
>> } [0x2f17 resolution 20]
>
> Can we have a variant with ${name} ${ref} to the mix? Or perhaps something
> like this:
>
> underground or train stations:
> ${ref|highway-symbol:hbox} $name
> tram stops:
> ${ref|highway-symbol:box} $name
> bus stops:
> ${ref|highway-symbol:oval} $name
>
> Nope, unfortunately the Edge 705 would display the highway-symbol:oval
> as a substitution character (solid diamond, similar to U+FFFD).
>
> Around here, there usually are at least two stops with the same name,
> on each side of the road. (Four if there are tram stops as well.)
> I would map all stops, especially if some of them are only reachable
> by bridges or tunnels.
>
> There will be a combinatorial explosion if there is no way to write
> this kind of rules:
>
> name += ref
> name += operator
>
> I tested this patch on my Edge 705. Bus stations are still listed with
> train stops and train stations in the Ground Transport menu.
>
> Index: mkgmap/resources/styles/default/points
> ===
> --- mkgmap/resources/styles/default/points (revision 1087)
> +++ mkgmap/resources/styles/default/points (working copy)
> @@ -85,7 +85,8 @@
> amenity=university [0x2c05 resolution 21]
> amenity=zoo [0x2c07 resolution 21]
>
> -highway=bus_stop [0x2f08 resolution 21]
> +highway=bus_stop | railway=tram_stop | railway=halt | railway=station { name
> '${name} ${ref} - ${operator}' | '${name} ${ref}' | '${name} - ${operator}' |
> '${ref} ${operator}' | '${name}' | '${ref}' | '${operator}' }
> +highway=bus_stop [0x2f17 resolution 20]
>
> highway=motorway_junction { name '${ref} ${name}' | '${ref}' | '${name}' }
> highway=motorway_junction [0x2000 resolution 16]
> @@ -133,7 +134,7 @@
>
> railway=halt [0x2f08 resolution 21]
> railway=station [0x2f08 resolution 20]
> -railway=tram_stop [0x2f08 resolution 21]
> +railway=tram_stop [0x2f17 resolution 21]
>
> shop=bakers [0x2e02 resolution 20]
> shop=bakery [0x2e02 resolution 20]
>
> Best regards,
>
> Marko
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
--
cheers,
maning
--
"Freedom is still the most radical idea of all" -N.Branden
wiki: http://esambale.wikispaces.com/
blog: http://epsg4253.wordpress.com/
--
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] listing all available POI in the point style
Hi, I tried to list all mapped POIs around my area and matched them to what code Garmin provides. Please have a look if I missed/misclassified some. There are some POIs that I can't find the proper garmin codes. Any advice? -- cheers, maning -- "Freedom is still the most radical idea of all" -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ -- points Description: Binary data ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] problems at map intersections?
2009/7/18 Garvan & maew > > Did anyone else notice this problem before? Were you able to reproduce >> it? If it helps, I can prepare a map that will have a routing problem >> just at the edge (there's a biking tunnel that MapSource avoids, no >> matter how hard I try, while letting mkgmap render the map without a >> boundary, the tunnel works just fine). >> >> Let me know if you need the map/script/other stuff to reproduce it. >> >> > I have been experimenting with maps with only one tile, but I did notice > the misalignment of the map selection box and the detailed map in mapsource. > I assumed it was a rounding issue between the detailed map and the overview > map which are at different scales, and never thought to report it as an > issue. For a large map it is almost unnoticeable, but for a small sample it > can be completely wrong. For small maps what I did was increased the size of > the bounding box in the osm file, and the alignment problem was fixed, or no > longer a problem, because the box was bigger than the tile. > > One reason why others have not reported this may be because they do not use > mapsource or QLandKarteGT. Those with external storage GPSr may never have > seen this misalignment. Or like me, they just adjusted the boundaries. > > Garvan > > > > > ___ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > Garvan, IMHO you misconcept real boundary overlay with the overview map overlay. There is in my opinion a problem that overview maps sometimes get created smaller than the actual map (i.e. when using gmaptool to create the mp overview map). I don't use mkgmap for overview map creation because it long was pretty buggy. Then in Mapsource maps will be cut off, while the data actually continues. Try a huge overview map (i.e. whole of europe) with your maps, to see if it is not an overview map problem instead of a real map data failure. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] problems at map intersections?
Did anyone else notice this problem before? Were you able to reproduce it? If it helps, I can prepare a map that will have a routing problem just at the edge (there's a biking tunnel that MapSource avoids, no matter how hard I try, while letting mkgmap render the map without a boundary, the tunnel works just fine). Let me know if you need the map/script/other stuff to reproduce it. I have been experimenting with maps with only one tile, but I did notice the misalignment of the map selection box and the detailed map in mapsource. I assumed it was a rounding issue between the detailed map and the overview map which are at different scales, and never thought to report it as an issue. For a large map it is almost unnoticeable, but for a small sample it can be completely wrong. For small maps what I did was increased the size of the bounding box in the osm file, and the alignment problem was fixed, or no longer a problem, because the box was bigger than the tile. One reason why others have not reported this may be because they do not use mapsource or QLandKarteGT. Those with external storage GPSr may never have seen this misalignment. Or like me, they just adjusted the boundaries. Garvan ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] problems at map intersections?
Hi Mark, Mark Burton schreef: > I believe (because the ML is not showered with emails complaining about > it failing) that inter-tile routing is generally working OK. It really does work great. In fact, it took me quite a while to come to the conclusion that the map edge seemed to be involved and that there might be a routing problem after all. At first I thought it was the tagging of tunnel, the fact that I tried to send a bike through a tunnel, the fact that I chose a bicycle for routing at all (Garmin doesn't do a really good job there - or maybe they like biking so much that they send you for 30 kilometer trips when 11 could do). But a few days ago I noticed that the map dissapeared at the same spot where the routing went wrong when I biked around with my Garmin Nuvi. Oh, and yes: I really think there aren't enough people riding around on their bicycles at OSM/splitter map edges, while looking at their Garmin Nuvis loaded with Openstreetmap-data in "Driving Direction Up" (i.e. non-3D), "Highest Detail", "Highest zoom" mode. I really should start a support group ;-) > Please provide an example of it failing so we can study it. memory=1700m maxn=50 wget 'http://download.geofabrik.de/osm/europe/netherlands.osm.bz2' bzcat netherlands.osm.bz2 > netherlands.osm wget 'http://www.mkgmap.org.uk/snapshots/mkgmap-latest.tar.gz' tar -zxf mkgmap-latest.tar.gz wget 'http://www.mkgmap.org.uk/splitter/splitter.jar' java -Xmx$memory -jar ./splitter.jar --max-nodes=$maxn netherlands.osm java -enableassertions -Xmx$memory -jar mkgmap*/mkgmap.jar \ --country-name=Nederland --country-abbr=NL --latin1 \ --remove-short-arcs --lower-case --route --preserve-element-order \ --location-autofill-1 --gmapsupp --net 63240008.osm.gz 63240010.osm.gz Then load the resulting map in MapSource; to be sure, select Edit-Preferences-Routing, Bicycle, shortest distance. (Set detail to Highest if you want to see the biking path). Then route from N52.42701 E4.82707 to N52.42625 E4.82736, they are on the same biking path, some 80 metres apart. You'll see the route deviate 3 kilometers. Also, if you try to zoom on one of the points above, you'll see a blank map. (This is Mapsource 6.11.5 running under Wine, but as said before: my Garmin Nuvi does the same - only on highest zooming level though, and only around the edges on the OSM map - it does not do that on the Garmin native map - I did check that). I hope you can reproduce my findings - that would be a help. Thanks so far, best regards, Valentijn -- Durgerdamstraat 29, 1507 JL Zaandam; telefoon 075-7074579 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] problems at map intersections?
Hi Valentijn, > Did anyone else notice this problem before? Were you able to reproduce > it? If it helps, I can prepare a map that will have a routing problem > just at the edge (there's a biking tunnel that MapSource avoids, no > matter how hard I try, while letting mkgmap render the map without a > boundary, the tunnel works just fine). I believe (because the ML is not showered with emails complaining about it failing) that inter-tile routing is generally working OK. Please provide an example of it failing so we can study it. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] problems at map intersections?
Steve Ratcliffe schreef: >> What I found is the following. Splitting a file with a border will >> produce a file that has the exact "bounds", without the overlap, in the >> resulting map. > That is intentional; the bounds should not overlap and should meet exactly. Are you really (as in really-really-really) sure about the fact that the maps should not overlap? A map with overlapping bounds seemed to work better here - especially around the edges. (I hope I described the problem of getting a blank map sufficiently to reproduce it - it did not happen when I overlapped the maps). [...] > I think that three things must line up exactly, the tiles them selves, > the areas within the overview map and the areas in the TDB file. > Probably one or more of those are out of step. The overview map seems to suffer from some rounding problem, as the boundary was a bit shifted to right, up; then when I decreased the numbers, it was shifted left, down. Luckily, I know just enough about programming to know that you can't decrease an integer by .5 ;) > Its also possible that > it only goes wrong in certain circumstances such as +ve or -ve longitude. > The next step is to find out exactly which one is wrong and compare with > a working map if necessary. I can reproduce the problem of a blank map at different map intersections (see my first mail). The problem shows at highest zooming levels, when the boundary of the map is viewable (or sometimes just out of view). If it were only the difference between the overview map and the real map, you would expect the map to disappear when the overview rectangle would be out of sight, but that's not what happens. Did anyone else notice this problem before? Were you able to reproduce it? If it helps, I can prepare a map that will have a routing problem just at the edge (there's a biking tunnel that MapSource avoids, no matter how hard I try, while letting mkgmap render the map without a boundary, the tunnel works just fine). Let me know if you need the map/script/other stuff to reproduce it. Best regards, Valentijn -- Durgerdamstraat 29, 1507 JL Zaandam; telefoon 075-7074579 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] problems at map intersections?
Hi Since no one replies to my mail, I'll do it myself ;) Thanks for studying the problem so closely - it is very useful. What I found is the following. Splitting a file with a border will produce a file that has the exact "bounds", without the overlap, in the resulting map. That is intentional; the bounds should not overlap and should meet exactly. There is extra data in the file that extends beyond the bounds and mkgmap should cut the lines at exactly the bounds. Cutting the lines at the exact boundary is bes done in mkgmap rather than splitter for several reasons, for example you have to know whether something is a line or a polygon to know what to do. Then, in addToOverviewMap, I added "-1" to the minimum lat/lon values: int minLat = roundDown(bounds.getMinLat(), overviewMask) -1; int minLon = roundDown(bounds.getMinLong(), overviewMask) -1; I think that three things must line up exactly, the tiles them selves, the areas within the overview map and the areas in the TDB file. Probably one or more of those are out of step. Its also possible that it only goes wrong in certain circumstances such as +ve or -ve longitude. The next step is to find out exactly which one is wrong and compare with a working map if necessary. Cheers, ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v4] - beware of the bollards!
Howdy folks, Shall I commit this stuff or does it need more work? To recap, it stops routing across a bollard (or other POI that has access restrictions). It works OK except in the case where the start and end positions are close to the bollard. As previously discussed, that is probably not fixable given our current knowledge. So, if no one has any issues, I shall commit this in a day or two. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] problems at map intersections?
Hello list, I'm having a great time corresponding to myself here :) but these are my observations so far. Running Splitter, then Mkgmap.jar, then MapSetToolKit.exe, then Mapsource, the resulting submaps are shifted from their bounding box: they are about 2.4 kilometers left, up, from the map itself. (So you have a bounding box that does not bound the map). The resulting submaps have no overlap now, which results in strange behaviour around the edges of the map: 1) It looks like sometimes Mapsource doesn't know how to get to the other map - a sort of short-arc between maps; it will refuse to take certain ways and will stubbornly route you around something, even if it's a trivial, 50 meters route on the map. 2) Also, sometimes Mapsource (and my Garmin Nuvi) seem to choose the wrong submap to display data from - resulting in a blank screen instead of mapping information. This is best seen at high zooming levels. Now I tried to get around this. If I use splitter to output a header of writer.append(String.valueOf(Utils.toDegrees(extendedBounds.getMinLat(; instead of the regular bounds.getMinLat(), I'm getting better results - the maps now overlap. I decreased the bounds size in addToOverviewMap in mkgmap. But is probably not be the correct way, as the bounding box still seems a bit off - I'm guessing that now the map itself grows, which will only work as long as the result will round down to a value within the map itself? If I'm unlucky, the new bounding box will - again - be larger than the map? If I knew Java, I would try to get Splitter to output something like Utils.toDegrees(bounds.getMinLat() + (extra / 2)), but as I don't know enough about scope of variables, I will leave that to more knowledgeable people. And maybe it's a stupid idea after all. I'll stop hacking around in unknown code now and have a beer, but my feeling is that 1) something should be done about the bounds in the overview map 2) I'm guessing that Garmin wants some overlap in submaps, so it can choose from what file to display the data from. Maybe 1 and 2 are the same problem (i.e. if the bounds are right, the choice of map will be right as well). I realise that I should have tried to hack an area.list with overlap, then use --split-file=areas.list, which is easier than randomly hacking around the source. Anyway. Maybe someone with knowledge of Mkgmap could say something about it? Best regards, Valentijn -- Durgerdamstraat 29, 1507 JL Zaandam; telefoon 075-7074579 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] problems at map intersections?
Hi, Since no one replies to my mail, I'll do it myself ;) Warning: I'm not much of a programmer and I just looked around in the mkgmap source for the first time today, so there's more things that I don't understand than there are things that I do understand. What I found is the following. Splitting a file with a border will produce a file that has the exact "bounds", without the overlap, in the resulting map. For example I have an area.list entry that has: 63240008: 2428928,153600 to 2443264,231424 # : 52.119141,3.295898 to 52.426758,4.965820 ... then the resulting map has exactly these: So from the bounds section, you seem to have lost the overlap you produced. However, the map does contain the overlap, which you can clearly see when you load the map in JOSM. As I said in my previous mail, something seems to go wrong at the edges of splitted maps, Mapsource showing a shifted bounds rectangle and seeming to choose the wrong map (i.e. one without data) at some zooming levels. After fiddling with the data and putting some random numbers in the mkgmap source, I think I know what Garmin wants us to do: - it wants to know the bounds including some overlap: splitter.jar should have output: (... which is a larger area, 0.02203 is added - which is the deviation I measured in Mapsource. Maybe I'm being stupid here and the 0.02203 number is a random number, has a meaning due to rounding, or whatever. I don't know - it works for me). Then, in addToOverviewMap, I added "-1" to the minimum lat/lon values: int minLat = roundDown(bounds.getMinLat(), overviewMask) -1; int minLon = roundDown(bounds.getMinLong(), overviewMask) -1; ... which results in a rectangle that is slightly larger. For some obscure reason, the bounding rectangle looks shifted in Mapsource, having minLat and minLon decreased by 1 just seems to work. I'm not sure if my Gärmïn Ñüvï likes this map as well, but I'll give it a try shortly. Best regards, Valentijn Valentijn Sessink schreef: > When trying to use a built map, I'm getting a bit odd results around the > edges of tiles - at least, I think it's the edges. It's not exactly on > the boundaries, but about 2.5 kilometers below the grey lines that show > up in Mapsource (I assume these are the tiles). But strangely, the > Splitter arealist has other numbers than Mapsource tells me. [...] ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] More on Routing
Steve Hosgood wrote: > Mark Burton wrote: >> Hi Paul, >> >> >>> Bury to CHester however starts along the M66, goes straight through >>> junction 18 to the next junction where you go all the way round the >>> roundabout, come back on yourself to junction 18 and then turn left onto >>> the M60 where the route is then as expected.This odd behaviour then >>> continues if routing to places further afield that require the same >>> initial route. >>> >>> http://www.openstreetmap.org/?lat=53.5497&lon=-2.261&zoom=14&layers=B000FTF >>> >>> shows the junctions involved but I can't see how it can be data errors >>> as some routes go M66, M62 westbound without problem and all 3 >>> destinations mentioned above are on the same tile >>> >> >> Can't explain why >> you're seeing badness there. >> >> > > I might. > > If Paul used XAPI to extract a part of the country in order to build his > Garmin map then it's possible that his XAPI excerpt isn't complete. I've > been seeing more and more of this happening in South Wales where I'm > doing exactly that. > > It seems (from other comments here) that there's a known problem with > the various XAPI servers occasionally dropping a minute-diff and never > recovering. I've seen this happening since the switch to the 0.6 API: I > had never noticed it before that. > > I've been sent on bogus routes around Swansea (my home town) due to > small bits of roads going missing. I've got a partially missing > westbound carriageway on a dual carriageway in one particular case, I've > also spotted a missing urban one-way street and a few other cases. > > If Paul looks carefully, does he spot (on the Garmin) a missing > slip-road on a roundabout, responsible for there being no valid route > from one side of a dual carriageway? Worse is an apparently present > slip-road on a dual carriageway where the 'oneway' once pointed the > wrong way, but has been fixed on OSM at some point, but where the fix > was part of a minute-diff that the XAPI server dropped? > > Steve > I use the Geofabrik mirror to download the great_britain.osm from http://download.geofabrik.de/osm/europe/great_britain.osm.bz2 I then use splitter r33 and usually the most current mkgmap to compile my maps using time java -Xmx2048M -jar -enableassertions mkgmap.jar --latin1 --gmapsupp --route --region-name="Great Britain" --region-abbr="GBR" --remove-short-arcs --stylefile=$stylefiles --max-jobs --net --code-page=1252 --country-name="GREAT BRITAIN" --country-abbr=GBR --tdbfile --tdb-v4 --description="Map of GB" --family-name="Great Britain" 70??.osm $srtmdir/uk*.osm This also wouldn't explain why I could route from Bury to Roe Green turning west at J18 yet Bury to Chester goes straight through that juction only to turn round at the next and come back to J18 and then go past Roe Green Cheers Paul ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Commit: r1088: Separate out the map number and the map name for the TDB file.
Version 1088 was commited by steve on 2009-07-17 14:28:22 +0100 (Fri, 17 Jul 2009) Separate out the map number and the map name for the TDB file. You can specify a separate name and number for the overview map. - Anton Todorov ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] More on Routing
> If Paul used XAPI to extract a part of the country in order to build his > Garmin map then it's possible that his XAPI excerpt isn't complete. I've > been seeing more and more of this happening in South Wales where I'm > doing exactly that. > > It seems (from other comments here) that there's a known problem with > the various XAPI servers occasionally dropping a minute-diff and never > recovering. I've seen this happening since the switch to the 0.6 API: I > had never noticed it before that. > > I've been sent on bogus routes around Swansea (my home town) due to > small bits of roads going missing. I've got a partially missing > westbound carriageway on a dual carriageway in one particular case, I've > also spotted a missing urban one-way street and a few other cases. > > If Paul looks carefully, does he spot (on the Garmin) a missing > slip-road on a roundabout, responsible for there being no valid route > from one side of a dual carriageway? Worse is an apparently present > slip-road on a dual carriageway where the 'oneway' once pointed the > wrong way, but has been fixed on OSM at some point, but where the fix > was part of a minute-diff that the XAPI server dropped? I thought that XAPI was totally buggered at the moment. I haven't been able to use it for weeks (months?) I am currently using: http://download.geofabrik.de/osm/europe/great_britain.osm.bz2 Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] More on Routing
Mark Burton wrote: Hi Paul, Bury to CHester however starts along the M66, goes straight through junction 18 to the next junction where you go all the way round the roundabout, come back on yourself to junction 18 and then turn left onto the M60 where the route is then as expected.This odd behaviour then continues if routing to places further afield that require the same initial route. http://www.openstreetmap.org/?lat=53.5497&lon=-2.261&zoom=14&layers=B000FTF shows the junctions involved but I can't see how it can be data errors as some routes go M66, M62 westbound without problem and all 3 destinations mentioned above are on the same tile Can't explain why you're seeing badness there. I might. If Paul used XAPI to extract a part of the country in order to build his Garmin map then it's possible that his XAPI excerpt isn't complete. I've been seeing more and more of this happening in South Wales where I'm doing exactly that. It seems (from other comments here) that there's a known problem with the various XAPI servers occasionally dropping a minute-diff and never recovering. I've seen this happening since the switch to the 0.6 API: I had never noticed it before that. I've been sent on bogus routes around Swansea (my home town) due to small bits of roads going missing. I've got a partially missing westbound carriageway on a dual carriageway in one particular case, I've also spotted a missing urban one-way street and a few other cases. If Paul looks carefully, does he spot (on the Garmin) a missing slip-road on a roundabout, responsible for there being no valid route from one side of a dual carriageway? Worse is an apparently present slip-road on a dual carriageway where the 'oneway' once pointed the wrong way, but has been fixed on OSM at some point, but where the fix was part of a minute-diff that the XAPI server dropped? Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] show oneway streets (and other mapping information)
> In my previous post i proposed a patch that solve this problem but it is > still not observed nor committed. I don't know why? :( Sorry about that, I think that the patch is good, I've been busy with other things in last few months, but I should have more time soon. Also the ordinary mapnames do not have to be integers either, not just the overview name. So I'd like the patch to be extend to cover all names. And it would probably be a good idea to make a MapName object to keep the name and number together. I'll commit the patch as it is now. Regards, ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] show oneway streets (and other mapping information)
- Original Message ... > overview-mapname > Filename of over view map without the extension. I found this must be a > number > if the map is to displayed in MapSource, but this appears to be a MKGMAP > requirement, not a GARMIN requirement. > ... Well I can confirm that statement. IMHO the real mess is in the overview .img and .tdb files. The parameter shuold be divided to something like: overview-mapname -> any string name, used as filename overview-mapid -> 8digit number, representing the "root" id that is assigned to overview map in TDB file and that is chained to slave detail mapids. In my previous post i proposed a patch that solve this problem but it is still not observed nor committed. I don't know why? :( BR, Anton Todorov ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [patch] change bus_stop to Transit Service category and add name / operator
Hi Ben,
On Fri, Jul 17, 2009 at 02:14:36AM -0400, Ben Konrath wrote:
> Here's a patch to change the highway=bus_stop POI to the Transit Service
> category and add the name and/or operator. As usual, comments are
> welcome.
Good idea! This will nicely separate bus stops and train stops. Maybe
use the same symbol code also for tram stops?
> -highway=bus_stop [0x2f08 resolution 21]
> +highway=bus_stop { name '${name} - ${operator}' | '${name}' | '${operator}'
> } [0x2f17 resolution 20]
Can we have a variant with ${name} ${ref} to the mix? Or perhaps something
like this:
underground or train stations:
${ref|highway-symbol:hbox} $name
tram stops:
${ref|highway-symbol:box} $name
bus stops:
${ref|highway-symbol:oval} $name
Nope, unfortunately the Edge 705 would display the highway-symbol:oval
as a substitution character (solid diamond, similar to U+FFFD).
Around here, there usually are at least two stops with the same name,
on each side of the road. (Four if there are tram stops as well.)
I would map all stops, especially if some of them are only reachable
by bridges or tunnels.
There will be a combinatorial explosion if there is no way to write
this kind of rules:
name += ref
name += operator
I tested this patch on my Edge 705. Bus stations are still listed with
train stops and train stations in the Ground Transport menu.
Index: mkgmap/resources/styles/default/points
===
--- mkgmap/resources/styles/default/points (revision 1087)
+++ mkgmap/resources/styles/default/points (working copy)
@@ -85,7 +85,8 @@
amenity=university [0x2c05 resolution 21]
amenity=zoo [0x2c07 resolution 21]
-highway=bus_stop [0x2f08 resolution 21]
+highway=bus_stop | railway=tram_stop | railway=halt | railway=station { name
'${name} ${ref} - ${operator}' | '${name} ${ref}' | '${name} - ${operator}' |
'${ref} ${operator}' | '${name}' | '${ref}' | '${operator}' }
+highway=bus_stop [0x2f17 resolution 20]
highway=motorway_junction { name '${ref} ${name}' | '${ref}' | '${name}' }
highway=motorway_junction [0x2000 resolution 16]
@@ -133,7 +134,7 @@
railway=halt [0x2f08 resolution 21]
railway=station [0x2f08 resolution 20]
-railway=tram_stop [0x2f08 resolution 21]
+railway=tram_stop [0x2f17 resolution 21]
shop=bakers [0x2e02 resolution 20]
shop=bakery [0x2e02 resolution 20]
Best regards,
Marko
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
