[mkgmap-dev] [Patch v1] Oneway handling

Tue May 14 22:01:13 BST 2013

Hi WanMil,

yes, thinking again about it maybe the patch solves no existing problem. If
a oneway line has a different 
type it will not be merged with a non-oneway line. If the device calculates
the direction of the arrows based on the order of points, no matter how
small the angle is, then the patch is completely obsolete
as long as we don't want to merge routable lines.
Thanks for pointing this out!

Gerd

WanMil wrote
> Hi Gerd,
> 
> I don't know if your patch makes sense or not.
> But let's start thinking loud (the following thoughts might be 
> completely wrong!!!):
> 
> The LineMergeFilter should not modify routing at all. This is (should 
> be?) catched by the rule that lines are merged only if resolution < 24 
> or the line is no road. That also means that merging is only a cosmetic 
> and performance change.
> Cosmetic: the lines are getting longer and therefore they will be 
> visible to resolutions with lower number because the subsequent filter 
> work better with longer lines.
> Performance: fewer objects and smaller img size for the device to display.
> 
> Merging of lines changes the behaviour of subsequent filters. You've 
> found a good example with Minkos way and the DouglasPeuckerFilter. When 
> having a look at this example I think the LineMergeFilter should not 
> merge lines to closed ways (unless they are roundabouts). If a way is 
> already closed it should not be merged any more.
> 
> Despite the absence of detailed knowledge of the map format I think that 
> the oneway flag should not matter in resolutions < 24. Overlays with 
> oneway arrows depend on the fact that they use a typ file with specific 
> images. Having two ways A (oneway=yes) and B (oneway=no) you will have 
> three MapLine objects:
> Object 1 type 0x06 derived from A
> Object 2 type 0x1022 derived from A which paints the oneway arrows
> Object 3 type 0x06 derived from B
> You can merge 1 with 3 because 2 will remain and will still paint the 
> oneway arrows. But 1 and 3 doesn't depend on being oneway or not. This 
> is interesting only for the routing layer, isn't it?
> 
> So from my point of view it should benefit more to have a look which 
> operations in the filters modify the routing network and eliminate them.
> This might be performed by creating a textual output of the routing 
> layer. The create an output before the filters are applied and a second 
> output with filters applied. Both outputs should be identical.
> 
> WanMil
> 
>> Hi,
>>
>> attached is a patch that should fix cosmetic issues with merge-lines and
>> oneways.
>>
>> The idea:
>> 1) merge-lines should not merge two lines if one is a oneway and one is
>> not
>> 2) merge-lines should not merge two oneway lines if the angle between
>> the two ways is too small (< 30°).
>> Not sure what it does with roundabouts.
>>
>> Please try this if your style creates overlays for oneways. I don't
>> expect any changes in routing.
>> Compiled version is here:
>> |http://files.mkgmap.org.uk/download/123/mkgmap.jar|
>>
>> @Steve: Please can you check if the implemented test reg. bearings makes
>> sense?
>>
>> Gerd
>>
>>
>>
>>
>> _______________________________________________
>> mkgmap-dev mailing list
>> 

> mkgmap-dev at .org

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

> mkgmap-dev at .org

> http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

--
View this message in context: http://gis.19327.n5.nabble.com/Patch-v1-Oneway-handling-tp5760958p5761040.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.