[mkgmap-dev] Short Arc Problem? Error 3 Mapsource, Problem on Calculating this route Basecamp.

Thu Jan 3 20:07:58 GMT 2013

Okay, now I get it. I think it would be better to have some sorts of 
multipolygon file similar to the relations file in the style though.
At least for everything that's a highway, it should be added to the 
original way.

So here is what I would expect:

Output:
way 114405617 [highway=tertiary; ref=GI-681; 
mp_created_highway=residential; area=yes]
way 81232137 [area=yes; highway=residential; mkgmap:mp_created=true; 
mkgmap:stylefilter=polyline]
relation 1596434 [area=yes; highway=residential; type=multipolygon]
way P1596434 [area=yes; highway=residential; mkgmap:mp_created=true; 
mkgmap:stylefilter=polygon]

I'm not so sure about area=yes though if it should be added as 
mp_created_area=yes instead. However if it had a name, but way 114405617 
would not have a name=XYZ, then it should be name I suppose and not 
mp_created_name=XYZ

This special multipolygon treatment, would only need to be done for MP 
with highway=*, the rest could stay as it is right now.

The outcome with the routing_error.patch is currently (with # = missing).

# way 114405617 [highway=tertiary; ref=GI-681]
way 81232137 [no tags]
way C114405617 [area=yes; highway=residential; mkgmap:mp_created=true; 
mkgmap:stylefilter=polyline]
way C81232137 [area=yes; highway=residential; mkgmap:mp_created=true; 
mkgmap:stylefilter=polyline]
way P1596434 [area=yes; highway=residential; mkgmap:mp_created=true; 
mkgmap:stylefilter=polygon]

so that's not very good either.

On 03.01.2013 20:56, WanMil wrote:
> Yes it's confusing. So let's track it down.
>
> Input:
> way 114405617 [highway=tertiary; ref=GI-681]
> way 81232137 [no tags]
> relation 1596434 [area=yes; highway=residential; type=multipolygon]
>
> Output of the mp algorithm:
> way 114405617 [highway=tertiary; ref=GI-681]
> way 81232137 [no tags]
> way C114405617 [area=yes; highway=residential; mkgmap:mp_created=true; 
> mkgmap:stylefilter=polyline]
> way C81232137 [area=yes; highway=residential; mkgmap:mp_created=true; 
> mkgmap:stylefilter=polyline]
> way P1596434 [area=yes; highway=residential; mkgmap:mp_created=true; 
> mkgmap:stylefilter=polygon]
>
> C114405617 is a copy of 114405617
> P1596434 is the resulting polygon of the mp.
>
> Is it now more clear?
>
> WanMil
>
>> But I still don't get it fully.
>> Is the MP creating a new line, or adding the tags?
>>
>> Because now there would be two conflicting highway keys...
>>
>> I think it would be good to have a behaviour to only add keys to the
>> underlying line, but not overwrite or not double if its a line...
>> because I don't think I can add a check like:
>> highway=* & highway=residential & mkgmap:mp_created=true {delete
>> highway=residential}
>>
>> (without deleting both highway keys...).
>>
>>
>> Are there any cases, where we really need highways from multipolygon in
>> case highway already exists on the line itself?
>> On 03.01.2013 20:17, WanMil wrote:
>>> Maybe it helps if I explain what happens in detail with the mp:
>>>
>>> 1. The mp calculates the tags for the mp. In this case the tags of the
>>> mp are used which are [area=yes; highway=residential]
>>> 2. These mp tags are removed from all outer ways if they are
>>> identical. In this case no tag is removed from way 114405617.
>>> 3. All outer ways are copied and tagged with the mp tags. These copied
>>> ways are only processed by the line style file. They can be identified
>>> by the additional tag mkgmap:mp_created=true.
>>> 4. All outer polygons are tagged with the mp tags and are processed by
>>> the polygon style file only. They can also be identified by the
>>> additional tag mkgmap:mp_created=true.
>>>
>>> Point 2 and 3 are required because in OSM the mp *and* the outer ways
>>> are tagged quite often.
>>>
>>> In this case it creates a residential way (point 3) with identical
>>> coords like the tertiary way 114405617.
>>>
>>> WanMil
>>>
>>>
>>>> But that change causes problems for other parts. There are some
>>>> highway=residential areas without ways that cross them, so in order to
>>>> have routing work in some inner city cases, you must make sure that 
>>>> you
>>>> route along the edges.
>>>>
>>>> If multipolygons were treated the same way as relations, that would 
>>>> make
>>>> it easier to make sure only one routable highway gets created (because
>>>> add highway onto highway would not add the highway, because there is
>>>> already an underlying highway).
>>>>
>>>>
>>>> The only thing I could think that does cause problems, if two routable
>>>> lines are on top of each other, and both have the same road_type and
>>>> same road_speed. Maybe there could be a check in the mkgmap continue
>>>> function, never to create two routable lines on top of each other, if
>>>> both road_speed and road_type are identical.
>>>> On 03.01.2013 14:44, Minko wrote:
>>>>>
>>>>> The issue also disappears when you use
>>>>> highway=residential & area!=yes [0x06 road_class=0 road_speed=2
>>>>> resolution 22]
>>>>> instead of the default rule
>>>>> highway=residential [0x06 road_class=0 road_speed=2 resolution 22]
>>>>>
>>>>> So it got to do with those two routable lines on top of each other
>>>>>
>>>>>
>>>>
>>>
>>
>

-- 
keep on biking and discovering new trails

Felix
openmtbmap.org & www.velomap.org