Diagnostic warnings for dead-end oneway highway=service

classic Classic list List threaded Threaded
29 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Diagnostic warnings for dead-end oneway highway=service

Marko Mäkelä
There are some dead-end highway=service,oneway=yes that trigger
dead-end-check warnings in mkgmap RouteNode.java.

To allow suppressing most of the warnings, years ago I added a check
that suppresses the warning if either end node of the way is tagged with
fixme=* or FIXME=*, such as fixme=continue. This is not always
applicable, for example when the oneway highway=service is leading to a
tunnel, which is omitted from the map in order to avoid clutter (such as
ways for underground parking) in city areas.

I figured out that it would be nice to display all tags of the dead-end
oneway, like we do in MultiPolygonRelation, so that my mkgmap wrapper
script could filter out any oneway warnings for highway=service.  
Unfortunately, the RoadDef is in the Garmin domain, and there is no
RoadDef.toTagString() method.

Any ideas how to improve the diagnostics?

        Marko
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Diagnostic warnings for dead-end oneway highway=service

Gerd Petermann
Hi Marko,

I think the dead-end test can be done in StyledConverter.
The test is quite similar to the one that is done in findUnconnectedRoads().

Gerd

Marko Mäkelä wrote
There are some dead-end highway=service,oneway=yes that trigger
dead-end-check warnings in mkgmap RouteNode.java.

To allow suppressing most of the warnings, years ago I added a check
that suppresses the warning if either end node of the way is tagged with
fixme=* or FIXME=*, such as fixme=continue. This is not always
applicable, for example when the oneway highway=service is leading to a
tunnel, which is omitted from the map in order to avoid clutter (such as
ways for underground parking) in city areas.

I figured out that it would be nice to display all tags of the dead-end
oneway, like we do in MultiPolygonRelation, so that my mkgmap wrapper
script could filter out any oneway warnings for highway=service.  
Unfortunately, the RoadDef is in the Garmin domain, and there is no
RoadDef.toTagString() method.

Any ideas how to improve the diagnostics?

        Marko
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Diagnostic warnings for dead-end oneway highway=service

Marko Mäkelä
On Mon, Dec 30, 2013 at 01:25:34PM -0800, GerdP wrote:
>I think the dead-end test can be done in StyledConverter.
>The test is quite similar to the one that is done in findUnconnectedRoads().

This sounds reasonable to me. The sooner the validation checks are done,
the better, because we will have a more direct connection to the style
language and the OSM data. This is the direction that mkgmap has been
following recently, thanks to you and WanMil.

Unfortunately I cannot spend much time in coding (I get too much of it
at my day job). I can volunteer to test patches and do some analysis on
the output.

Best regards,

        Marko
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Diagnostic warnings for dead-end oneway highway=service

Gerd Petermann
Hi Marko,

okay, I'll have a look at it during the next days.

Gerd

> Date: Tue, 31 Dec 2013 14:13:54 +0200

> From: [hidden email]
> To: [hidden email]
> Subject: Re: [mkgmap-dev] Diagnostic warnings for dead-end oneway highway=service
>
> On Mon, Dec 30, 2013 at 01:25:34PM -0800, GerdP wrote:
> >I think the dead-end test can be done in StyledConverter.
> >The test is quite similar to the one that is done in findUnconnectedRoads().
>
> This sounds reasonable to me. The sooner the validation checks are done,
> the better, because we will have a more direct connection to the style
> language and the OSM data. This is the direction that mkgmap has been
> following recently, thanks to you and WanMil.
>
> Unfortunately I cannot spend much time in coding (I get too much of it
> at my day job). I can volunteer to test patches and do some analysis on
> the output.
>
> Best regards,
>
> Marko
> _______________________________________________
> mkgmap-dev mailing list
> [hidden email]
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Diagnostic warnings for dead-end oneway highway=service

Marko Mäkelä
Hi Gerd,

>okay, I'll have a look at it during the next days.

Thanks!

BTW, the diagnostics is not completely useless as it is now; it does
include labels, which (when present) will identify the ways. But, in
addition to normally unnamed highway=service, there could be some ways
that are accidentally left unnamed, such as when splitting a way to a
dual carriageway near a junction (Y-shaped). Then, both "oneway arms" of
the "Y" could accidentally point to the same direction, which would
trigger a warning.

        Marko
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Diagnostic warnings for dead-end oneway highway=service

Gerd Petermann
Hi Marko,

attached is a patch for the high-prec-coord branch to perform the
dead-end-check in StyledConverter.
I did not remove the original code, so both tests are performed
now. I think this helps to find differences.
Please note that both checks will not recognize restriction relations
which prohibit to enter or leave a oneway.
A compiled binary based on r2930 can be found here:
http://files.mkgmap.org.uk/download/166/mkgmap.jar

Gerd


> Date: Thu, 2 Jan 2014 15:29:19 +0200

> From: [hidden email]
> To: [hidden email]
> Subject: Re: [mkgmap-dev] Diagnostic warnings for dead-end oneway highway=service
>
> Hi Gerd,
>
> >okay, I'll have a look at it during the next days.
>
> Thanks!
>
> BTW, the diagnostics is not completely useless as it is now; it does
> include labels, which (when present) will identify the ways. But, in
> addition to normally unnamed highway=service, there could be some ways
> that are accidentally left unnamed, such as when splitting a way to a
> dual carriageway near a junction (Y-shaped). Then, both "oneway arms" of
> the "Y" could accidentally point to the same direction, which would
> trigger a warning.
>
> Marko
> _______________________________________________
> mkgmap-dev mailing list
> [hidden email]
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

deadendcheck_v3.patch (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Diagnostic warnings for dead-end oneway highway=service

Gerd Petermann
In reply to this post by Marko Mäkelä
Hi Marko,

Marko Mäkelä wrote
I figured out that it would be nice to display all tags of the dead-end
oneway, like we do in MultiPolygonRelation, so that my mkgmap wrapper
script could filter out any oneway warnings for highway=service.  
I am not sure if I got that right. If you want to suppress the
dead-end-check for all ways with specific tags,
you can do it in the style (add the tag mkgmap:dead-end-check=false to the way)

Gerd
Reply | Threaded
Open this post in threaded view
|

Re: Diagnostic warnings for dead-end oneway highway=service

Marko Mäkelä
Hi Gerd,

>>I figured out that it would be nice to display all tags of the
>>dead-end oneway, like we do in MultiPolygonRelation, so that my mkgmap
>>wrapper script could filter out any oneway warnings for highway=service.
>
>I am not sure if I got that right. If you want to suppress the
>dead-end-check for all ways with specific tags, you can do it in the
>style (add the tag mkgmap:dead-end-check=false to the way)

I do not want to suppress dead-end-checks altogether. I do it on a
case-by-case basis, either by adding fixme=continue to the endpoint
(this will set mkgmap:dead-end-check=false on the way; I wrote the code
to do that), or by filtering out messages.

Here is a slightly different example:

... Motorway exit 67
(http://www.openstreetmap.org/?mlat=60.47712&mlon=26.27170&zoom=17) has
no motorway!

This is for node 1909615887. The message fails to mention the tags of
the attached way 181498435 (highway=construction, construction=motorway,
...).

I have a file that I pass to "grep -vf" for suppressing known warnings.  
I would not want to add a suppression for this message as it is now,
because it would remain suppressed after the construction is completed
and the way gets tagged highway=motorway. If my suppression regexp were
something like

Motorway exit 67 .*mlat=60\.47712&mlon=26\.27170.*highway=construction

then it would no longer suppress the warning if the way is changed to
highway=motorway and some map editor breaks something. (Even better than
coordinates would be the ID of the highway=motorway_exit node.)

        Marko
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Diagnostic warnings for dead-end oneway highway=service

Gerd Petermann
Hi Marko,

okay, let me know if the patch works for you.

Gerd
Marko Mäkelä wrote
Hi Gerd,

>>I figured out that it would be nice to display all tags of the
>>dead-end oneway, like we do in MultiPolygonRelation, so that my mkgmap
>>wrapper script could filter out any oneway warnings for highway=service.
>
>I am not sure if I got that right. If you want to suppress the
>dead-end-check for all ways with specific tags, you can do it in the
>style (add the tag mkgmap:dead-end-check=false to the way)

I do not want to suppress dead-end-checks altogether. I do it on a
case-by-case basis, either by adding fixme=continue to the endpoint
(this will set mkgmap:dead-end-check=false on the way; I wrote the code
to do that), or by filtering out messages.

Here is a slightly different example:

... Motorway exit 67
(http://www.openstreetmap.org/?mlat=60.47712&mlon=26.27170&zoom=17) has
no motorway!

This is for node 1909615887. The message fails to mention the tags of
the attached way 181498435 (highway=construction, construction=motorway,
...).

I have a file that I pass to "grep -vf" for suppressing known warnings.  
I would not want to add a suppression for this message as it is now,
because it would remain suppressed after the construction is completed
and the way gets tagged highway=motorway. If my suppression regexp were
something like

Motorway exit 67 .*mlat=60\.47712&mlon=26\.27170.*highway=construction

then it would no longer suppress the warning if the way is changed to
highway=motorway and some map editor breaks something. (Even better than
coordinates would be the ID of the highway=motorway_exit node.)

        Marko
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Diagnostic warnings for dead-end oneway highway=service

Marko Mäkelä
In reply to this post by Gerd Petermann
On Thu, Jan 02, 2014 at 04:27:23PM +0100, Gerd Petermann wrote:
>attached is a patch for the high-prec-coord branch to perform the
>dead-end-check in StyledConverter.
>I did not remove the original code, so both tests are performed now. I
>think this helps to find differences.

Thanks! This looks verbose enough for my taste:

2014/01/02 19:42:16 WARNING (StyledConverter): 63240004.osm.pbf: Oneway
road 55835321 with tags
[oneway=yes,mkgmap:street=Pentinkaarre,name=Pentinkaarre,mkgmap:label:1=Pentinkaarre,highway=living_street,surface=paved]
goes to nowhere at
http://www.openstreetmap.org/?mlat=62.262185&mlon=24.710546&zoom=17

Maybe you could filter out the generated mkgmap:* tags, but I am OK with
it. I guess that the logging output is too verbose to be read directly
by a human anyway (without any searching or filtering, that is).

This way is (was) P-shaped. The oneway=yes would be OK for the D-shaped
loop of the P, but not for the 'foot'. I fixed this particular error,
but left others there, so that we can do more cross-checking with
subsequent patches.

I got 23 Oneway warnings with your branch+patch, and 13 with trunk. The
differences are as follows, after filtering out timestamps and sorting
both outputs:

* Different coordinates for the 13 old messages (as expected; this is
thanks to the higher precision)
* 'Extra' warning for the ways: 55835321 23152992 64148077 167346021
* 'Missing' warning for the ways: 200035193 220389737 25455464 42191422
53197410 131648853 50118184

The 'missing' warnings could be because the ways are connected to other
ways for which map is not being generated, such as a
highway=service,oneway=yes leading to a
highway=service,oneway=yes,tunnel=yes,... that is omitted from the map.  

IMO the 'missing' warnings should be emitted; we should be checking that
the generated map makes sense.

>Please note that both checks will not recognize restriction relations
>which prohibit to enter or leave a oneway.

Right. Ignorance is bliss. :)

A related note with oneways is that some mappers seem to generate
redundant turn restrictions for oneways. For example, they would add a
relation that prevents turning against the oneway from a motorway_link
to the motorway lane. I wonder if we should emit warnings for such
redundant relations?

Best regards,

        Marko
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Diagnostic warnings for dead-end oneway highway=service

Gerd Petermann
Hi Marko,
 
please check:
Marko Mäkelä wrote
* Different coordinates for the 13 old messages (as expected; this is
thanks to the higher precision)
I don't yet see a reason for different coordinates. Did you really compare
the output one program execution?
Or did you use a different program for the "old" messages?

Gerd
Reply | Threaded
Open this post in threaded view
|

Re: Diagnostic warnings for dead-end oneway highway=service

Marko Mäkelä
On Thu, Jan 02, 2014 at 11:19:06AM -0800, GerdP wrote:

>Hi Marko,
>
>please check:
>
>Marko Mäkelä wrote
>> * Different coordinates for the 13 old messages (as expected; this is
>> thanks to the higher precision)
>
>I don't yet see a reason for different coordinates. Did you really compare
>the output one program execution?
>Or did you use a different program for the "old" messages?

I did 2 comparisons with the output from 2 runs:

With mkgmap/trunk r2916
With mkgmap/branches/high-prec-coord r2930 and your patch

First, I compared the output of trunk to the output of branch, using the
finland.osm.pbf from Geofabrik dated today, 02:16 UTC.

There were 2 differences:

(a) Variation of the coordinates in the 13 old-style messages
(b) Addition of 10 new-style messages

This was to be expected.

What was not expected was the difference 13 vs. 10. To diagnose it,
I performed another comparison within the output of the patched branch.  
Many of the "old" messages had direct counterparts in the "new"
messages, but some "new" messages for "old" messages were missing, and
some were extra (only "new" message for the way, no "old" one).

In my previous message, I listed the OSM way IDs for both cases. I fixed
one error (for one extra "new" message) in the OSM database, but I left
the others intact, so that we will have some errors in the next
finland.osm.pbf to check against.

        Marko
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Diagnostic warnings for dead-end oneway highway=service

Gerd Petermann
Hi Marko,

okay, thanks for the explanation. I'll look at the differences tomorrow.

Gerd
Marko Mäkelä wrote
On Thu, Jan 02, 2014 at 11:19:06AM -0800, GerdP wrote:
>Hi Marko,
>
>please check:
>
>Marko Mäkelä wrote
>> * Different coordinates for the 13 old messages (as expected; this is
>> thanks to the higher precision)
>
>I don't yet see a reason for different coordinates. Did you really compare
>the output one program execution?
>Or did you use a different program for the "old" messages?

I did 2 comparisons with the output from 2 runs:

With mkgmap/trunk r2916
With mkgmap/branches/high-prec-coord r2930 and your patch

First, I compared the output of trunk to the output of branch, using the
finland.osm.pbf from Geofabrik dated today, 02:16 UTC.

There were 2 differences:

(a) Variation of the coordinates in the 13 old-style messages
(b) Addition of 10 new-style messages

This was to be expected.

What was not expected was the difference 13 vs. 10. To diagnose it,
I performed another comparison within the output of the patched branch.  
Many of the "old" messages had direct counterparts in the "new"
messages, but some "new" messages for "old" messages were missing, and
some were extra (only "new" message for the way, no "old" one).

In my previous message, I listed the OSM way IDs for both cases. I fixed
one error (for one extra "new" message) in the OSM database, but I left
the others intact, so that we will have some errors in the next
finland.osm.pbf to check against.

        Marko
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Diagnostic warnings for dead-end oneway highway=service

Gerd Petermann
Hi Marko,

found a few special cases:
1) the new dead-end-check is done before merging roads, so sometimes the
reported way ids in the old RouteNode check refer to merged roads.
When you want to compare results you should use --x-no-mergeroads
so that you see the correct way ids.
2) The new check did not ignore points that lie on the boundary, only those
that were outside of the tile boundary
3) The new check did not recognize P-shaped oneways as self-connecting.
4) The new check used a different (wrong) interpretation of the meaning of the LEVEL
parameter in --report-dead-ends=LEVEL option.

Attached is a new version of the patch.
One possible problem case in the new check: If a oneway X is connected to a
way Y that has just one (or more) identical points, the dead-end-check
for X will say that the way is not a dead end, but later the way Y will be deleted
with a corresponding warning and the old dead-end-check reports
the dead-end for way X.
I think this is okay as long as you see the warning for way Y.

Ciao,
Gerd

> Date: Thu, 2 Jan 2014 11:59:27 -0800

> From: [hidden email]
> To: [hidden email]
> Subject: Re: [mkgmap-dev] Diagnostic warnings for dead-end oneway highway=service
>
> Hi Marko,
>
> okay, thanks for the explanation. I'll look at the differences tomorrow.
>
> Gerd
>
> Marko Mäkelä wrote
> > On Thu, Jan 02, 2014 at 11:19:06AM -0800, GerdP wrote:
> >>Hi Marko,
> >>
> >>please check:
> >>
> >>Marko Mäkelä wrote
> >>> * Different coordinates for the 13 old messages (as expected; this is
> >>> thanks to the higher precision)
> >>
> >>I don't yet see a reason for different coordinates. Did you really compare
> >>the output one program execution?
> >>Or did you use a different program for the "old" messages?
> >
> > I did 2 comparisons with the output from 2 runs:
> >
> > With mkgmap/trunk r2916
> > With mkgmap/branches/high-prec-coord r2930 and your patch
> >
> > First, I compared the output of trunk to the output of branch, using the
> > finland.osm.pbf from Geofabrik dated today, 02:16 UTC.
> >
> > There were 2 differences:
> >
> > (a) Variation of the coordinates in the 13 old-style messages
> > (b) Addition of 10 new-style messages
> >
> > This was to be expected.
> >
> > What was not expected was the difference 13 vs. 10. To diagnose it,
> > I performed another comparison within the output of the patched branch.
> > Many of the "old" messages had direct counterparts in the "new"
> > messages, but some "new" messages for "old" messages were missing, and
> > some were extra (only "new" message for the way, no "old" one).
> >
> > In my previous message, I listed the OSM way IDs for both cases. I fixed
> > one error (for one extra "new" message) in the OSM database, but I left
> > the others intact, so that we will have some errors in the next
> > finland.osm.pbf to check against.
> >
> > Marko
> > _______________________________________________
> > mkgmap-dev mailing list
>
> > mkgmap-dev@.org
>
> > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
>
>
>
>
> --
> View this message in context: http://gis.19327.n5.nabble.com/Diagnostic-warnings-for-dead-end-oneway-highway-service-tp5791229p5791507.html
> Sent from the Mkgmap Development mailing list archive at Nabble.com.
> _______________________________________________
> mkgmap-dev mailing list
> [hidden email]
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

deadendcheck_v4.patch (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Diagnostic warnings for dead-end oneway highway=service

Marko Mäkelä
Hi Gerd,

>3) The new check did not recognize P-shaped oneways as self-connecting.

This was not a bug in the new check, but a bug in the old check!

I agree that by definition, looped ways cannot be dead ends.

For the purpose of detecting dead ends, we could ignore non-branching
loops formed by a sequence of ways. Actually, it does not matter if the
non-branching loops are oneway!

If there is no non-looped way connected to both ends of the "foot" of
the P, then the foot of the P forms a dead-end oneway. That is, a
P-shaped oneway should be treated just like an I-shaped oneway that is
obtained by removing the looped part.

Maybe you could use this idea to improve dead-end checks? Note that a
roundabout does not count as a non-branching loop, unless it is
connected to a single oneway flare road only.

>Attached is a new version of the patch.

Thanks, I will try it later for today's data. I already ran trunk and
the previous patch on the data.

>I think this is okay as long as you see the warning for way Y.

Me too, it is OK to be silent about some part of an error scenario, as
long as some of the connected ways get flagged. I usually download a
region around the problematic spot in order to figure out what the
intention is and how it should be fixed.

        Marko
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Diagnostic warnings for dead-end oneway highway=service

Gerd Petermann
Hi Marko,

reg. p-shaped:
The error was not in the foot, but in the other end. My understanding is that
that you can travel in that loop like in a roundabout, so it is not a dead end.

OK?

Gerd

>

> >3) The new check did not recognize P-shaped oneways as self-connecting.
>
> This was not a bug in the new check, but a bug in the old check!
>
> I agree that by definition, looped ways cannot be dead ends.
>
> For the purpose of detecting dead ends, we could ignore non-branching
> loops formed by a sequence of ways. Actually, it does not matter if the
> non-branching loops are oneway!
>
> If there is no non-looped way connected to both ends of the "foot" of
> the P, then the foot of the P forms a dead-end oneway. That is, a
> P-shaped oneway should be treated just like an I-shaped oneway that is
> obtained by removing the looped part.
>
> Maybe you could use this idea to improve dead-end checks? Note that a
> roundabout does not count as a non-branching loop, unless it is
> connected to a single oneway flare road only.
>
> >Attached is a new version of the patch.
>
> Thanks, I will try it later for today's data. I already ran trunk and
> the previous patch on the data.
>
> >I think this is okay as long as you see the warning for way Y.
>
> Me too, it is OK to be silent about some part of an error scenario, as
> long as some of the connected ways get flagged. I usually download a
> region around the problematic spot in order to figure out what the
> intention is and how it should be fixed.
>
> Marko
> _______________________________________________
> mkgmap-dev mailing list
> [hidden email]
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Diagnostic warnings for dead-end oneway highway=service

Gerd Petermann
Hi Marko,

okay, thinking again about endlessly traveling in a loop I guess it is a special form
of a deadend when there is no other exit ;-)
At the moment I have no idea how we can separate the
two cases, but I agree that this should be handled.

Gerd


From: [hidden email]
To: [hidden email]
Date: Fri, 3 Jan 2014 15:10:27 +0100
Subject: Re: [mkgmap-dev] Diagnostic warnings for dead-end oneway highway=service

Hi Marko,

reg. p-shaped:
The error was not in the foot, but in the other end. My understanding is that
that you can travel in that loop like in a roundabout, so it is not a dead end.

OK?

Gerd

>

> >3) The new check did not recognize P-shaped oneways as self-connecting.
>
> This was not a bug in the new check, but a bug in the old check!
>
> I agree that by definition, looped ways cannot be dead ends.
>
> For the purpose of detecting dead ends, we could ignore non-branching
> loops formed by a sequence of ways. Actually, it does not matter if the
> non-branching loops are oneway!
>
> If there is no non-looped way connected to both ends of the "foot" of
> the P, then the foot of the P forms a dead-end oneway. That is, a
> P-shaped oneway should be treated just like an I-shaped oneway that is
> obtained by removing the looped part.
>
> Maybe you could use this idea to improve dead-end checks? Note that a
> roundabout does not count as a non-branching loop, unless it is
> connected to a single oneway flare road only.
>
> >Attached is a new version of the patch.
>
> Thanks, I will try it later for today's data. I already ran trunk and
> the previous patch on the data.
>
> >I think this is okay as long as you see the warning for way Y.
>
> Me too, it is OK to be silent about some part of an error scenario, as
> long as some of the connected ways get flagged. I usually download a
> region around the problematic spot in order to figure out what the
> intention is and how it should be fixed.
>
> Marko
> _______________________________________________
> mkgmap-dev mailing list
> [hidden email]
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

_______________________________________________ mkgmap-dev mailing list [hidden email] http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Diagnostic warnings for dead-end oneway highway=service

Marko Mäkelä
On Fri, Jan 03, 2014 at 03:29:22PM +0100, Gerd Petermann wrote:
>okay, thinking again about endlessly traveling in a loop I guess it is
>a special form of a deadend when there is no other exit ;-)

Right, that was what I had in mind. Generally, if the routing graph is
not strongly connected (it is not forming a single strongly connected
component) it should be a sign of invalid oneways. When there are no
oneway=* attributes, the routing graph will trivially be strongly
connected (you can get from anywhere to anywhere, because you can
traverse the edges in both directions).

A special case is when there are multiple routing islands even when
ignoring the oneway=* attributes. Within a map tile, we can legitimately
have multiple routing islands, for example if no ferry connection has
been mapped to an island, or when some ways in the tile are connected by
ways in adjacent tile(s).

We should only complain when the introduction of oneway=yes "splits" a
routing island.  

There is an efficient algorithm for computing the strongly connected
components of a directed graph:
http://en.wikipedia.org/wiki/Tarjan%27s_strongly_connected_components_algorithm

Perhaps we could invoke the algorithm in two passes:

(1) on the undirected graph of roads (hard-wiring oneway=no)
Each strongly connected component (SCC) would be a routing island.
(2) for each SCC from step 1 that contains oneway=yes attributes:
If the SCC would be split, list the oneway=yes ways (or some of them).

        Marko
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Diagnostic warnings for dead-end oneway highway=service

Marko Mäkelä
In reply to this post by Marko Mäkelä
On Fri, Jan 03, 2014 at 04:05:20PM +0200, Marko Mäkelä wrote:
>Thanks, I will try it later for today's data. I already ran trunk and
>the previous patch on the data.

Compared to the previous patch, the new patch is omitting warnings for
three P-shaped oneways: 23152992,64148077,167346021. (Also the old check
in trunk missed these.)

I fixed all these errors by removing the oneway=yes from the "foot" of
the P.

With the newer patch and the data from last night, the new check did not
report any issues that were missed by the old check. The new check
failed to report these ways that were flagged by the old check in trunk:  
200035193,220389737,25455464,42191422,53197410,131648853,50118184

        Marko
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Diagnostic warnings for dead-end oneway highway=service

Gerd Petermann
Hi Marko,

> With the newer patch and the data from last night, the new check did not
> report any issues that were missed by the old check. The new check
> failed to report these ways that were flagged by the old check in trunk:
> 200035193,220389737,25455464,42191422,53197410,131648853,50118184

Strange, after sorting I don't see a single difference for finland.

Please check:
When I split latest finland.osm.pbf with max-nodes=1000000
these ways are all close to tile boundaries
Results with my tiles:
200035193,42191422: not reported
220389737,25455464,53197410,131648853,50118184: reported by both checks

Please post one of your tiles (the input file) with a difference.

Attached is also the style that I use to test the dead-end-check.

Gerd



_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

finland-1000000.kml (16K) Download Attachment
deadend.zip (21K) Download Attachment
12