Hi Carlos,
> Here it is:
> java.lang.AssertionError: relative pointer too large for 14 bits (source
> offset = 1115876, dest offset = 1124268)
Thanks for that, it was useful.
Please try r1240, it could possibly fix the issue.
Cheers,
Mark
___
mkgm
v2 - now prints OSM URL of first point in dodgy roundabout.
As suggested, moved from rhd to dol.
Two options are now available --drive-on-left and --drive-on-right.
By default, you should not have to specify either because mkgmap now
determines the side of the road to drive on fro
v3 - now reverses the order of the points in roundabouts that have the
wrong direction so that routing is more likely to succeed.
v2 - now prints OSM URL of first point in dodgy roundabout.
As suggested, moved from rhd to dol.
Two options are now available --drive-on
Hi Marko,
You can always filter them out with grep if you don't want to see them.
Cheers,
Mark
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Marko,
> > You can always filter them out with grep if you don't want to see them.
>
> Sure, I could. However, many of the warnings have been genuine
> (such as sidewalks or cycleways being placed too close to the main road
> or main crossing). I would also like to see any new warnings as they
v4 - improved quality of direction detection
v3 - now reverses the order of the points in roundabouts that have the
wrong direction so that routing is more likely to succeed.
v2 - now prints OSM URL of first point in dodgy roundabout.
As suggested, move
Felix,
> Additionaly It would be great, if the "road-name-pois" option could be
> dropped
Just don't use it. Seriously, it was only intended to be a quick and
dirty way of being able to search for streets. When the global search
stuff matures it will almost certainly be redundant. But unless t
Felix,
> Ups, sorry I was not clear. I meant that we should include into the
> global address index also streets without "osm addresses". So that any
> street present in the map, can be searched for by the "address search"
> and not only proper addresses with housenumbers (because we don't ha
Hi Carlos,
> > Please try r1240, it could possibly fix the issue.
> Great, it fixed it
Good.
That was a long standing bug that only became active recently
due to me increasing a data structure size limit to what I believe it
should be.
Cheers,
Mark
Hi Marko,
> Can you give a hint how to achieve this? The warning would be issued
> by RoadNetwork.java, which seems to work in the imgfmt domain (RouteNode
> and RoadDef). How can I get the corresponding OSM node or way, so that
> I can see if a mkgmap:ignore-zero-length-arc property has been s
Hi Nakor,
> I have noticed that in case an exit node is linked to several highways
> (maybe this is bad mapping practice but it exists) and one of them does not
> have a ref tag, mkgmap issues a warning that the exit was not assigned a ref
> (see nodes 62152165 and 61852851 for an example).
>
>
v5 - added --check-roundabouts option to explicitly enabled
roundabout checking/reversing.
Not had much feedback on this yet, anyone (apart from Dermot) tried
it? Even if you don't drive on the left (almost the whole world?) you
may care to try out the roundabout checking. About 3% of all the GB
Hi Charlie,
> If there's a way you can share a pre-built jar file then I'd be happy to
> check it out as I spent ages fixing roundabouts in the Languedoc earlier
> this year.
I've mailed one directly to you.
> (Another common issue I've noticed is ways that don't meet: presumably
> these we
Hi Paul,
> Either you've fixed all the GB roundabouts or I've done something wrong
> as I get no additional output when compiling a map of GB with this patch
> applied.
>
> If you have fixed them all then I see no negative side effects either
I very much doubt that I've fixed every one so I thi
Paul,
I don't know about putting logging.properties into resources. I specify
the file to use by giving this option to java:
-Dlog.config=logging.properties
However, the logging.properties file I quoted did have different levels
of logging to the console and the log files, the console was less
Annoyingly, motorway exit POIs don't show up on my Nuvi so I thought
that the next best thing would be to label the exit roads with the exit
name (number). This patch does that in a generic way. It introduces a
new facility:
If a way (of highway type X) has a POI for its first point and that
Hi Dermot,
> That finally worked for me too. That revealed to me that there were in
> fact about 15 wrong-way roundabouts in Ireland. I'm happy to say that
> there are now none at all :D
Very good.
> One question, though - I'm also getting a few warnings like the following:
>
> 2009/10/03 15:
Hi Ralf,
> Hi all,
>
> I have build a map with version 1247 and the following options:
> --latin1 --route --tdbfile --remove-short-arcs --add-pois-to-areas
> --link-pois-to-ways
>
> Mapsource and my Etrex routes me through the bollards on "Marktstraße"
> (setting was for motorcar).
> http://www
Hi Ralf,
> I used the the default style file included. The last entries in points are:
> barrier=bollard | barrier=bus_trap
> {add access = no; add bicycle = yes; add foot = yes} [0x660f resolution
> 21]
> barrier=block | barrier=cycle_barier | barrier=stile | barrier=kissing_gate
> {add
The attached patch (which also includes the drive-on-left patch because
it's based on that) attempts to improve the quality of routing
instructions so that when a turn off a road that doesn't involve a big
heading change is required, the GPS should say "turn left/right" rather
than "keep left/righ
Hi Ralf,
I know what the problem is. The code currently checks for the access
tag before the style file is processed so if the bollard doesn't have
an access tag already, the POI isn't linked to the way as it needs to
be for this to work.
Sorry for the hassle, I shall dream up a fix. In the mean
Ralf,
> Sometimes I see the opposite problem: A road that splits into two roads,
> each at about 45 degree angle, and I'd like to get a "keep left" but its
> missing.
Well, it may be possible to fix that as well. I need to see a concrete
example so that I can understand what needs to be done.
C
Hi Martin,
> I also noticed this behavior at a bollard in my area.
> Since about the same time(~2 weeks ago), there also were problems with
> some turn restrictions being ignored.
If there are problems, it will be something else that's wrong because
they are not related.
> It seems to me that o
Hi Paul,
> When the turn restrictions were added was the no_u_turn restriction
> implemented as I have recently been told by my 605 to make a U turn
> where I have specifically added a no_u_turn restriction?
>
> I feel it's only fair to mention that some of these no_u_turn
> restrictions are fla
Hi Paul,
> Can I make this a feature request then? :) Consider the following
>
> A B C
> +--->
> |
> <---+
> D E| F
> |
> \/
> G
> ABC is oneway in direction ABC
> FED is oneway in direction FED
> BE is twoway but is
Hi Charlie,
> I must be doing something wrong. I've just run this on the UK using
> --drive-on-left and --check-roundabouts and it seems to be flagging
> roundabouts that are correct (i.e. clock-wise).
>
> Here's some examples:
> 2009/10/04 19:16:31 WARNING (StyledConverter): Roundabout 48318
Hi Carlos,
> Well, my ascii art is not so good ;-) . X should be on top of B.
I worked it out.
You're right, what I suggested won't work in that situation.
Cheers,
Mark
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org
v2 - various changes - should now work with junctions that have more
than 1 side road - should be able to treat exits from roundabouts in
the same way as side roads.
-
The attached patch (which also includes the drive-on-left patch because
it's based on that) attempts to
v2 - now based on r1260.
-
Annoyingly, motorway exit POIs don't show up on my Nuvi so I thought
that the next best thing would be to label the exit roads with the exit
name (number). This patch does that in a generic way. It introduces a
new facility:
If a way (of highway type X)
Hello Martin,
> 2009/10/4 Mark Burton :
> >
> > Hi Martin,
> >
> >> I also noticed this behavior at a bollard in my area.
> >> Since about the same time(~2 weeks ago), there also were problems with
> >> some turn restrictions being ignored.
>
v3 - now based on r1265. Added --adjust-turn-headings option to enable
this functionality. Reports now downgraded to info (from warn).
v2 - various changes - should now work with junctions that have more
than 1 side road - should be able to treat exits from roundabouts i
Hi Marko,
> I tried --drive-on-right --check-roundabouts, and the generated map is of
> the same size as with r1260. There are much more diffs than the time
> stamps, though. This is with 3 tiles and 2 cores.
The code that calculates the arc headings is probably producing a
slightly different
Hello Nakor,
> I have spotted a routing issue with a mkgmap generated map. I was able to
> reproduce it in several versions: 1188, 1228 and 1265.
Are you generating the map directly from the OSM files or are you
converting to Polish format and then generating the map from the Polish
files?
If t
I have committed the Java tweak required to support the naming of
motorway exit roads from the name/ref of a motorway_junction POI.
I haven't committed the required change in the style file because maybe
not everyone wants this to happen.
So, if you do, please add lines like this to your points
You are building your maps with assertions enabled, aren't you?
Cheers,
Mark
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Nakor,
> I can provide the osm data (22 Mb gzipped) if needed.
I think I need to see that because I tried with just a small region
around the problem area and it could route OK.
Can you put that data onto a web server somewhere?
Cheers,
Mark
___
Hi,
I can confirm that there are routing issues with that map, don't know
what the problem is at this time so I cannot give an ETA for a fix. I
will work on it as time allows.
Cheers,
Mark
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
ht
Hi Andre,
> I just accidentally found an issue in mkgmap. When creating a
> gmapsupp.img with a TYP file, mkgmap throws an exception if this file is
> readonly. When the TYP file is writable, this exception is not thrown.
> But I think, that mkgmap should never write to a TYP file, should it?
Th
v4 - now writes arc curve data that encodes the final heading of an arc.
This should yield better quality routing instructions when an arc's
final heading differs greatly from its initial heading.
At this time, only single byte curve data is being written and the
format of that is not 100% confir
Hi Felix,
> Is there currently a possibility with mkgmap to display highway symbols
> without adding them to the name?
>
> The following format:
> highway=motorway {name '${ref|highway-symbol:hbox} ${name}' }
>
> causes problems with searching streets, if you know the streetname but
> not th
Hi Nakor,
I haven't yet discovered why it appears to be impossible to cross
certain longitudes. I will keep thinking about it and, hopefully,
come up with a solution sometime.
However, that map is riddled with non-connected ways so even if the bug
is fixed, routing will still be very unreliable
I want to dissuade my gps from using very narrow roads (for car routing)
so one way of doing that is to reduce the road class and/or speed if the
road is narrower than some threshold. I can easily imagine how to do
that in mkgmap using some new Java code but I suspect that it could be
done using s
Hi Dermot,
> > It probably has to cope with widths that have either m or ft suffix
> > (I have also seen widths in the UK as 6'6" !). Can the style file hack
> > that?
>
> This, of course, is why units really suck in fields that could so
> easily be strictly numeric...
The OSM wiki says:
Descr
Hi Carlos,
> I would like to know what's the effect of duplicate nodes on rutting.
> Some areas of Spain are full of them (I have already fixed more than
> 60.000 in the Northwest).
Duplicate nodes break routing because mkgmap makes no attempt to connect
ways even if the coordinates of the dup
Hi Clinton,
Thanks for the response.
> I suspect you could do it with something like the following:
>
> highway= primary & (width=narrow | width < 2 | est_width < 2) [0x04
> road_class=2 road_speed=3 resolution 20]
>
> highway=primary [0x03 road_class=3 road_speed=4 resolution 19]
>
> (This
This is something that was briefly discussed not too long ago and the
idea is that a road's speed or class can be modified by the
presence of a POI that defines new values for either/both of them. This,
hopefully, will make ways that have stuff like traffic signals and
crossings, etc. less attract
I have received zero feedback on the recent arc tweezing patch. I
believe that in its latest form (v4), it provides much improved
routing instruction quality. In particular, it should give you fewer
instructions to keep left/right or even turn left/right when you are
continuing on a long road (lik
Hi Felix,
> Mark Burton wrote:
> > This is something that was briefly discussed not too long ago and the
> > idea is that a road's speed or class can be modified by the
> > presence of a POI that defines new values for either/both of them. This,
> > hopefully, wil
On Wed, 14 Oct 2009 08:45:52 +0200
Ralf Kleineisel wrote:
> On 10/14/2009 01:14 AM, Mark Burton wrote:
>
> > These tags expect an integer value, optionally preceded by a + or -
> > which make the adjustment relative to the original value.
>
> This is a good idea.
>
Hi Chris,
> Does it work with and without the --ignore-maxspeeds option?
>
It occurs after the maxspeed processing.
> By the why: Is the --ignore-maxspeeds option documented
> somewhere? All I understand is that it turns off
> the default mkgmap handling of maxspeed tags, so that
> only the ro
Just realised, as the patch is now, it will only apply one delta to the
way's speed/class. If a way has multiple POIs that can change the
speed/class, only the last one processed (the order is, essentially,
random) will have an effect.
Cheers,
Mark
___
Felix,
> While writing action rules to try out the link pois to roads I just
> wondered whether mkgmap only looks at access/bicycle/motorcar =no or
> also other values like = delivery / destination / forestry /
> agricultural / private ?
It only looks at vehicle classes as in the list you
Felix,
> O.k. so where do I find the other values?
What other values?
> Actually can I delete some access mapping lines if I don't want them -
> this would be easier than working with action rules.
>
> So if I crunch the below list down to
>
> # new AccessMapping("access", RoadNetwor
Felix,
Thanks for spelling it out to me.
> >> O.k. so where do I find the other values?
> >>
> Well, if you said not only =no has an effect, what happens to
> access=destination or access=private - AFAIK Garmin only accepts yes or
> no, so which of the values (permissive, private, deliver
> It would be great to have --delete-tags="motorcar,motorcycle (private/no)"
> Actually I'm a bit afraid of people putting access=no motorcar=forestry
> but forgetting bicycle=yes or foot=yes.
>
> What would best be --delete-tags"/resources/deletetags" and put all tags
> with values into that
Hi Felix,
Many thanks for the report - comments inline.
> Okay, I have played around now over 1 hour in Mapsource (allways
> creating two identical route start/endpoints and calculating with two
> maps identical if not for the tweeze arc patch and then comparing the
> choses routes) and just
Hello Ivan,
> I think I found where my extended-type lines disappear. They are simply not
> taken into account when estimating subdivision size, i.e:
>
> MapArea.java, lines 389-394
>
> private void addSize(MapElement p, int[] sizes, int kind) {
>
> ->if(p.hasExtendedType()) {
> ->
Hi Ivan,
> I will try to play with small-area osm contour file (as lines are usually
> ordered by elevation) and map them via style to extended lines. There will
> be no subdivision split as there are no other elements that will cause it.
> Last lines drawn (i.e. certain elevation) would indicate
Hi Valentijn,
Thanks for the report.
On Wed, 14 Oct 2009 17:00:55 +0200
Valentijn Sessink wrote:
> Mark Burton schreef:
> > I have received zero feedback on the recent arc tweezing patch.
>
> Ehrm, eh, yes. Whatever destination I have in mind lately, I always seem
> to
Hi Ivan,
It took me a little longer than expected (as I decided to revamp what
was there) but I have a patch for you to try (attached).
This limits the size of the extended type elements to 32KB for each of
the points/lines/shapes. I have no idea if that is a sensible limit but
you can alter it
v2 - you can now have mkgmap:road-class-min and mkgmap:road-class-max
tags (and the same for the road speed) that will limit the final value
used. These can either be added to the POI (from whence they will be
transferred to the way by mkgmap) or directly to the way.
-
This
Felix,
> Just a small question. If I add to a poi { add road_speed_min='-1'; add
> road_speed_min='1' } what happens if the original road had road_speed=0
> will it be increased or stay at 0?
> (I assume and hope for the latter).
Yes, the min/max tags only have an effect if mkgmap:road-speed o
Here's the thing we talked about earlier. I'm too tired to write about
it now but the code should work well enough for people to evaluate. The
option file blurb tells you how to use it.
Feedback, etc.
Mark
diff --git a/resources/help/en/options b/resources/help/en/options
index bf7a587..6cba35b
Felix,
Last email for today - i'm fried.
> >> Just a small question. If I add to a poi { add road_speed_min='-1'; add
> >> road_speed_min='1' } what happens if the original road had road_speed=0
> >> will it be increased or stay at 0?
> >> (I assume and hope for the latter).
> >>
> >
> >
Hi Ivan,
> I does immediately solve the problem. I played a bit with increasing the
> above values and I started receiving 'holes' in the 'contour test' at
> highest zoom (resolution 24) after 0x1ff00 (i.e. 0x2ff00). So I backed off
> and left it at 0xff00, to be safe, and now it works fine with
Felix,
> How shall I merge this, it is conflicting - when using the patch version
> mkgmap does not compile.
Attached is a version of the patch that applies on top of the tweeze
arcs patch.
It would be good to commit the tweeze arcs patch as it affects quite a
few files and makes it difficult
Felix,
> Working Great!
>
> Saves me about 10% processing time compared to removing access tags via
> style-file as action rules!
> Also gets rid of stupid things like ref=0 that are present on loads of
> roads in Austria due to the import.
Very good - if you are happy with what it does, I
Felix,
> > Are you happy that the tweeze arcs stuff doesn't actually break
> > anything (compared to before)? If so, I shall commit it in its present
> > form
> Better than the status quo, so would support committing it (and also for
> a merge of the mdr branch into trunk, because at some point
Felix,
> Could you commit the "continue" patch too?
Sorry, I would prefer not to dabble with the style code.
Mark
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Given that they have had some amount of testing and no reported
breakage, I have committed my recent gaggle of patches to trunk so that
it becomes easier to build. Apologies in advance if anything is now
messed up (worse than before!)
Hopefully, Steve will be able to merge in the mdr branch soon
Hi Ivan,
> I tested mostly with MapSource but from previous experience, behavior is
> consistent (i.e. when things start to disappear) with at least Garmin
> Mobile XT. I tested today my map with Garmin Mobile XT and everything seems
> to be in place so MAX_XT_* values of 0xff00 should be safe a
hello world
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Sorry, ignore this - posted to ML by mistake.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Carlos,
> What happens if the distance between the tagged POI and the
> next/previous points is very long? Shouldn't it be a limit to the length
> affected by the reduction/increase of road_speed/road_class?
Arguably, yes. However, I ran out of energy before I could implement
that. The bollar
Carlos,
> > Arguably, yes. However, I ran out of energy before I could implement
> > that. The bollard code does very similar things but, to be honest, I
> > can't really be bothered at this time. If someone else wants to
> > implement that, I will happily integrate their patch. My feeling was
>
Just trying out this new option and I get:
Could not open /home/markb/OSM/M000.TYP when creating mdr file
Now I can see that it's barfing on the TYP file that I want to include
in my gmapsupp.img.
Is it possible to ignore the TYP file as far as the MDR is concerned or
do I have to change ho
Hi Steve,
> What Felix said is true, but all the same it should be ignoring that
> file when building the index. Now fixed.
Thanks for the fix.
Actually, I don't know anything about reversing the index - are you
planning to implement that capability so that we don't have to
use mapsource at a
As part of my current thrust to improve the mapping of the world's
roundabouts, I have added an option that checks the sanity of
roundabout flare roads. It probably can be fooled by some valid data
but it's pretty good at finding bad roundabout flares. Specifically,
it's looking for these errors:
Hi Paul,
> I was recently travelling south down the M61 and turned off this to head
> east along the M65. After joining the slip road from the M61 the
> directions I were given were to keep right to the roundabout and then
> take the 1st exit off the roundabout. As you can see there is a feeder
>
Hi Felix,
> Could someone please recheck the "continue" patch for the
> --link-pois-to-ways action?
> If using --link-pois-to-ways all lines created with "continue" command
> that are affected by a POI are not shown/created.
I am not familiar with the continue patch but if you post it (or emai
Hi Felix,
> here is the last version (working up to 1277 flawless)
Well, I can't see where the problem is at the moment. I did find and
fix a trivial bug while looking at the code introduced by 1278 so the
time was not wasted!
When you say "created with continue command", what does that mean? C
Felix,
> highway=* & oneway=yes {set name "{name} oneway"} [0x27 resolution 24
> continue]
> highway=residential [0x07 resolution 22]
>
> Usually now every street with oneway=yes I have an additional line
> displaying small arrows to indicate street is oneay.
> However using link-pois-to-ways
Felix,
forget that last patch - it doesn't do the copy early enough - I shall
rework it.
Mark
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
OK, let's try again. The attached patch adds a duplicate() method to
the Way class.
It's only really needed when using the continue patch. You will have to
edit StyledConverter.class in the do while loop where it's
looping around until foundType.isFinal() and in the body of the loop
it is calling
> Thanks for your work, doesn't show any improvements for me however (but
> adds about 25% to compile time).
25% is a huge overhead, that's not just the time taken to duplicate
the way. Perhaps the lines really are getting processed in their
entirety now and some other reason is causing them no
> Ups, sorry replied to myself when wanting to correct the above
> statement. Compile time did not increase, I had some background indexing
> running at the same time. On second run it was more or less the same as
> allways.
OK - no problem.
Does the output change size when using duplicate(
Felix,
> It got a tiny bit larger (Austria 56.5 to 57.7 MB) but I can see no
> other difference and I looked for differences for a long time comparing
> back and forth. If I disable the --link-pois-to-ways maps actually gets
> smaller (57.2 MB) but the ways are all inside.
> So something do
Felix,
> okay - 1.st all my patches against trunk (current revision) that I have
> applied.
> 2. StyleedCoverter.java
Thanks for those - but I don't see you using duplicate()? Can you send
me the copy of StyledConverter.java that you tried putting the
duplicate() into?
Thanks,
Mark
__
Felix,
> The patch that you published (I only used the second one, as you said I
> should forget about the first one) only applies to way.java
> I attach it here for you. Maybe you assumed that I use some sort of
> additional patch on StyledConverter.java too, which you forgot on the list?
N
Felix,
> Uups, read too fast and only applied the patch. Would not have
> understood your first explanation anyhow (would not compile if I only
> exchanged that line instead of adding the aditional else call).
>
> Now it's working :-) !
Jolly good.
I will commit the duplicate() patch.
Ma
Hi Torsten,
> Do you have an example, how this feature can be used?
>
> What use do you see for it? (This was propably answered in another
> thread, but I have missed the reasoning.)
It was added to solve a problem that Felix discovered when creating
multiple lines/roads from a single way (usin
Hi Marco,
> I'm using mkgmap very often and meanwhile it's working really good,
> but I found something, that some img files are broken. After integrating
> it into Mapsource,
> MS is crashing with an error xx.img has an broken record.
> How can I help you to find the problem? What do you
Hi Marco,
> yes I can do. But before we start huge debugging.
> I found out, that these file were bigger then 20 MB.
> Could this be a limitation of mkgmap?
> I recreated the maps with low "max-nodes" in splitter, the file became
> smaller and it works, now.
> Is there a know issue?
There's al
Hi Marco,
> Yes I know that it's experimental software. I asked for known issues
> concerning a file size over 20MB?
> No I do not use assertion. Do you still need the map file, or shall I
> rebuild the maps with assertion first?
Yes, please rebuild with assertions enabled and see if you get any
Hi Marko,
> Thanks, with the logging.properties from
> http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2009q3/003993.html
> I got some warnings about roundabouts and fixed a few already.
Good, glad it's useful to you.
> I did not find the old discussion on a problematic roundabout, so I cannot
>
Hi Marko,
> In the warning output of finland.osm, I see 219 warnings about
> turn restriction relations. Apparently, there not that many errors
> in the map data, because I see duplicates, like this:
>
> 2009/10/20 15:39:32 WARNING (RestrictionRelation): Turn restriction 167929
> has multiple
Hi Marko,
> Could I get the two sets of warnings because I am running with --max-jobs=2?
> Would it be possible to suppress the duplicate warnings, or at least
> display a download URL for each violation, e.g., for the 'via' node?
I've added the OSM URL into the turn restriction messages.
As fo
Hi Toby,
> It might be an idea to report the erroneous ways using the 'browse' URL
> of that way. For example:
> http://www.openstreetmap.org/browse/way/34875101 >
It already reports an OSM download URL suitable for use in JOSM or a
web browser. I find that extremely useful for fixing the prob
> Version 1305 was commited by markb on 2009-10-22 10:45:48 +0100 (Thu, 22 Oct
> 2009)
>
> Message tweak - s/road/street/.
Oops, that should have said s/street/road/. So much for shorthand!
Anyway, it's a good new feature - I found over 40 locations in the GB
map where oneway roads met up wit
Hi Marko,
> I believe that report-dead-ends: 1 is issuing a bogus error with r1308 here:
>
> 2009/10/22 22:03:07 WARNING (RouteNode): Confluence of oneway roads
> (Laukaantie, 38626392), (637 Laukaantie, 38626390) at
> http://www.openstreetmap.org/?lat=62.29304&lon=25.81349&zoom=17
>
> As far
401 - 500 of 986 matches
Mail list logo
