Hi Felix,

Maybe we have different ideas what merging of labels means.
With r4149 I've implemented this:
If way w1 has e.g. mkgmap:label:1 = "Main Street" and mkgmap:label:2 = "N 232" 
(a ref)
and way w2 has only mkgmap:label:1 = "Main Street" mkgmap adds mkgmap:label:2  
from the first way.
Also if w2 has e.g. mkgmap:label:1 = "Main Place" the merged result would be
mkgmap:label:1 = "Main Street"
mkgmap:label:2 = "N 232"
mkgmap:label:3 = "Main Place"
I did not yet test if that really works with address search, also there is no 
method to detect which way is w1 and which is w2.
Probably order of appearance.

Another option would be to somehow concatenate labels, esp. those from ref 
tags, but I have no idea how to code that
as every style might use differents ways to combine refs.

Gerd

________________________________________
Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Felix 
Hartmann <extremecar...@gmail.com>
Gesendet: Mittwoch, 4. April 2018 12:46:44
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] overlapping highways and route restrictions

okay that's fine. I think the result will lead to nearly no more actual problem 
cases...

On 4 April 2018 at 12:44, Gerd Petermann 
<gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>> wrote:
Hi Felix,

you may try r4147. I plan to add code to merge different labels of overlapping 
ways, I think I can't do much more.

Gerd

________________________________________
Von: mkgmap-dev 
<mkgmap-dev-boun...@lists.mkgmap.org.uk<mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>>
 im Auftrag von Felix Hartmann 
<extremecar...@gmail.com<mailto:extremecar...@gmail.com>>
Gesendet: Mittwoch, 4. April 2018 11:44:05
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] overlapping highways and route restrictions

Yes I think that could be problematic. I'm not sure how it will end up. I do 
not create routable lines from the relations file directly, I use the set 
command and then in the lines file the additional ways are created - so that if 
one line has 1 or X route relations, there will be no difference. However that 
assumes they are all added to the same line I guess. So if different routes are 
copied onto different overlapping ways this principle would go wrong - it won't 
be a problem if the underlying overlaying ways are moved/merged before the 
handling of the relations however.

I have so far seen mostly cases where two overlaying ways were both part of the 
same route relation - not of different route relations.

On 4 April 2018 at 11:10, Gerd Petermann 
<gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com><mailto:gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>>>
 wrote:
Hi Felix,

well, you started to mention route relations:
"The case of overlapping ways being part of different route relations on the 
other hand I've seen quite often - in that case I think it's best to just add 
all route relations to one way, and remove the other one."
My understanding is that the code in mkgmap doesn't have to care about route 
relations (e.g. type=route, route=bicycle), this is done in the style. With 
your style those might cause more trouble because you add more routable lines 
for the members but the current overlap remover will only remove segments with 
more or less identical attributes.
What you suggest requires a completely different approach, right?

Gerd

________________________________________
Von: mkgmap-dev 
<mkgmap-dev-boun...@lists.mkgmap.org.uk<mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk><mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk<mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>>>
 im Auftrag von Felix Hartmann 
<extremecar...@gmail.com<mailto:extremecar...@gmail.com><mailto:extremecar...@gmail.com<mailto:extremecar...@gmail.com>>>
Gesendet: Mittwoch, 4. April 2018 10:58:43
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] overlapping highways and route restrictions

yes I know - but even though both ways you linked have different turn 
restriction ID - the content of the turn restriction is identical (only 
straight on).

On 4 April 2018 at 10:54, Gerd Petermann 
<gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com><mailto:gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>><mailto:gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com><mailto:gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>>>>
 wrote:
Hi Felix,

yes, 1) would handle the case in my example.
Just to make sure: I meant turn restrictions, not route relations.

Gerd

________________________________________
Von: mkgmap-dev 
<mkgmap-dev-boun...@lists.mkgmap.org.uk<mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk><mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk<mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>><mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk<mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk><mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk<mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>>>>
 im Auftrag von Felix Hartmann 
<extremecar...@gmail.com<mailto:extremecar...@gmail.com><mailto:extremecar...@gmail.com<mailto:extremecar...@gmail.com>><mailto:extremecar...@gmail.com<mailto:extremecar...@gmail.com><mailto:extremecar...@gmail.com<mailto:extremecar...@gmail.com>>>>
Gesendet: Mittwoch, 4. April 2018 10:48:20
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] overlapping highways and route restrictions

For my maps 1) is enough - and warning not even needed. I think it's hard to 
find out what the outcome should be.
The case of overlapping ways being part of different route relations on the 
other hand I've seen quite often - in that case I think it's best to just add 
all route relations to one way, and remove the other one.

The example you found here - I think is quite possible to solve - both 
restriction relations are identical - so one way including the restriction 
relation can be removed, the route relations copied over. If the restriction is 
having different rules - then however I don't think we can solve it correctly 
(well an exception is if we have overlapping ways in OSM which are oneway and 
opposite to each other - this is a rare case where overlapping ways are not to 
be removed I guess).



On 4 April 2018 at 10:39, Gerd Petermann 
<gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com><mailto:gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>><mailto:gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com><mailto:gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>>><mailto:gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com><mailto:gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>><mailto:gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com><mailto:gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>>>>>
 wrote:
Hi all,

please help, I just try to make up my mind what mkgmap should do when it finds 
overlapping road segments and
one (or both) of the overlaps is a part of a (valid) restriction relation.  
This doesn't happen very often, but it is possible.

The attached example contains these two overlapping ways, and both are members 
of (different) restriction relations:
https://www.openstreetmap.org/way/48218016
https://www.openstreetmap.org/way/48218008

(I did not try what the trunk version produces for this mess)

I see different possibilities:
1) ignore route restrictions when removing overlaps, remove those which are 
invalid after overlapping segments were removed and log a warning
2) ignore overlaps when the ways are members of restriction relations
3) complex: remove overlaps but try to "repair" the restriction

I am currently trying to implement 3) but it looks too complicated for such a 
rare case and in the end we have a clear case of wrong input data here.
What do you think?

Gerd


_______________________________________________
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>>>
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev



--
Felix Hartman - Openmtbmap.org & VeloMap.org
Schusterbergweg 32/8
6020 Innsbruck
Austria - Österreich
_______________________________________________
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>>
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev



--
Felix Hartman - Openmtbmap.org & VeloMap.org
Schusterbergweg 32/8
6020 Innsbruck
Austria - Österreich
_______________________________________________
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev



--
Felix Hartman - Openmtbmap.org & VeloMap.org
Schusterbergweg 32/8
6020 Innsbruck
Austria - Österreich
_______________________________________________
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev



--
Felix Hartman - Openmtbmap.org & VeloMap.org
Schusterbergweg 32/8
6020 Innsbruck
Austria - Österreich
_______________________________________________
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Reply via email to