> Are you happy with the current state of the merge patch? If so, I can
> commit it to trunk.
>
>
Yes, the current state seems cause no problems. The comments from the
testers are not discouraging.
From my side you can commit it. Maybe somtimes in the future mkgmap
will be refactored and the
Johann,
> The merge lines patch is designed from start for high line numbers. It
> uses internal hashlists for performance reasons. I would expect the
> runtime to raise n*log(n), not n². So I do not expect it to burn cpu,
> but would need a test to proove it.
OK.
> But I'm not sure, if merg
>>> That's a shame but the upside of only merging within a subdivision is
>>> that it's really quick.
>>>
>>>
>> Would it be possible to merge lines across more subdivisions or is this
>> a natural limit?
>>
>
> I can't be 100% sure without some study but I think it should be
> pos
Felix,
> not destroying anything, but also not helping. Restrictions are still
> set by the first way (using continue) the second routable way
> restrictions set via {} are not enacted. Oneway also not changed.
Well, I tried an example like yours but could not get any sense out of
it at all.
Johann,
> >
> > I'm being so stupid today, it's the subdivisions. The lines that are
> > not matching are in different subdivision so they don't get compared.
> >
> >
> Thanks for the hint, this was it. I have noted that the lines are not
> merged at subdivisions, but not thought to the final
>
> I'm being so stupid today, it's the subdivisions. The lines that are
> not matching are in different subdivision so they don't get compared.
>
>
Thanks for the hint, this was it. I have noted that the lines are not
merged at subdivisions, but not thought to the final end. I think its
time
> Hi Johann,
>
> Been trying your patch and it works well. Certainly doesn't seem to
> break the routing. However, it doesn't always merge ways that, as far
> as I can tell, should be merged. I have studied your code so I know how
> you're doing the matching. One thought, would rounding the coords
Hello again,
> Been trying your patch and it works well. Certainly doesn't seem to
> break the routing. However, it doesn't always merge ways that, as far
> as I can tell, should be merged. I have studied your code so I know how
> you're doing the matching. One thought, would rounding the coords
Hi Johann,
Been trying your patch and it works well. Certainly doesn't seem to
break the routing. However, it doesn't always merge ways that, as far
as I can tell, should be merged. I have studied your code so I know how
you're doing the matching. One thought, would rounding the coords
before mer
Johann Gail wrote:
I noticed that some Garmin maps display 1:1 to openstreetmap data,
but on route calculation show up to 10% shorter distance. Maybe here
only routing nodes are simplifed (straighter line).
Sorry, could you explain in more detail? I'm not sure what you mean
here.
'Si
>>>
>>> I noticed that some Garmin maps display 1:1 to openstreetmap data,
>>> but on route calculation show up to 10% shorter distance. Maybe here
>>> only routing nodes are simplifed (straighter line).
>>
>> Sorry, could you explain in more detail? I'm not sure what you mean
>> here.
>> 'Simp
Mark Burton wrote:
Standby...
Attached, completely untested, probably destroy the universe...
not destroying anything, but also not helping. Restrictions are still
set by the first way (using continue) the second routable way
restrictions set via {} are not enacted. Oneway also not ch
> I actually think that one should even thing about simplifying routable
> ways at resolution=24. Especially those that directly originate from
> GPS tracks (that will be difficult to find out though), maybe only if
> nodes are closer than 20m over longer distances. So say 6 nodes in 60m
> oka
Mark Burton wrote:
Felix,
I don't know what's the difference between patch v3 and patch v2, but v3
makes no practical improvement. Yes it sets the different speeds and
road_class for 0x01 and 0x02, but impossible to set different
restrictions, they are simply dropped.
Having made
> Standby...
Attached, completely untested, probably destroy the universe...
diff --git a/src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java b/src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java
index abc8941..d314fd4 100644
--- a/src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java
+
Felix,
> I don't know what's the difference between patch v3 and patch v2, but v3
> makes no practical improvement. Yes it sets the different speeds and
> road_class for 0x01 and 0x02, but impossible to set different
> restrictions, they are simply dropped.
Having made a complete fool of myse
Johann Gail wrote:
Mark Burton schrieb:
Hi Felix (cc Johann)
Just as a follow up, I noticed that the v8 patch (simplify ...) -
actually routing over long distances in Mapsource became worse. Some
routes I can calculate without using this patch, don't calculate with
the patch any
Hi Johann,
Thanks for taking the time to explain your patch.
> Seems you missed the important fact, that the merging takes place only
> at resolutions <=23. As far as I understand the whole thing, line data
> at lower resolutions is used only for displaying.
Yes, I missed that crucial point.
Mark Burton schrieb:
> Hi Felix (cc Johann)
>
>
>> Just as a follow up, I noticed that the v8 patch (simplify ...) -
>> actually routing over long distances in Mapsource became worse. Some
>> routes I can calculate without using this patch, don't calculate with
>> the patch anymore.
>>
Mark Burton wrote:
Hi Felix,
No Johanns (v8) patch actually improves long distance routing (2-3
additional turns), while the remove bogus roads makes long distance
routing worse for me (3-4 turns less). Sorry for the wrong text.
OK, thanks for clarifying that. My comments in the
Hi Felix,
> No Johanns (v8) patch actually improves long distance routing (2-3
> additional turns), while the remove bogus roads makes long distance
> routing worse for me (3-4 turns less). Sorry for the wrong text.
OK, thanks for clarifying that. My comments in the last message can
therefor
Mark Burton wrote:
Hi Felix (cc Johann)
Just as a follow up, I noticed that the v8 patch (simplify ...) -
actually routing over long distances in Mapsource became worse. Some
routes I can calculate without using this patch, don't calculate with
the patch anymore.
You posted this c
Hi Felix (cc Johann)
> Just as a follow up, I noticed that the v8 patch (simplify ...) -
> actually routing over long distances in Mapsource became worse. Some
> routes I can calculate without using this patch, don't calculate with
> the patch anymore.
You posted this comment with a subject l
23 matches
Mail list logo
