Felix,
> Uups, read too fast and only applied the patch. Would not have
> understood your first explanation anyhow (would not compile if I only
> exchanged that line instead of adding the aditional else call).
>
> Now it's working :-) !
Jolly good.
I will commit the duplicate() patch.
Ma
Mark Burton wrote:
Felix,
The patch that you published (I only used the second one, as you said I
should forget about the first one) only applies to way.java
I attach it here for you. Maybe you assumed that I use some sort of
additional patch on StyledConverter.java too, which you forgo
Felix,
> The patch that you published (I only used the second one, as you said I
> should forget about the first one) only applies to way.java
> I attach it here for you. Maybe you assumed that I use some sort of
> additional patch on StyledConverter.java too, which you forgot on the list?
N
Mark Burton wrote:
Felix,
okay - 1.st all my patches against trunk (current revision) that I have
applied.
2. StyleedCoverter.java
Thanks for those - but I don't see you using duplicate()? Can you send
me the copy of StyledConverter.java that you tried putting the
duplicate() into?
Felix,
> okay - 1.st all my patches against trunk (current revision) that I have
> applied.
> 2. StyleedCoverter.java
Thanks for those - but I don't see you using duplicate()? Can you send
me the copy of StyledConverter.java that you tried putting the
duplicate() into?
Thanks,
Mark
__
Felix,
> It got a tiny bit larger (Austria 56.5 to 57.7 MB) but I can see no
> other difference and I looked for differences for a long time comparing
> back and forth. If I disable the --link-pois-to-ways maps actually gets
> smaller (57.2 MB) but the ways are all inside.
> So something do
Mark Burton wrote:
Ups, sorry replied to myself when wanting to correct the above
statement. Compile time did not increase, I had some background indexing
running at the same time. On second run it was more or less the same as
allways.
OK - no problem.
Does the output change siz
> Ups, sorry replied to myself when wanting to correct the above
> statement. Compile time did not increase, I had some background indexing
> running at the same time. On second run it was more or less the same as
> allways.
OK - no problem.
Does the output change size when using duplicate(
Mark Burton wrote:
Thanks for your work, doesn't show any improvements for me however (but
adds about 25% to compile time).
25% is a huge overhead, that's not just the time taken to duplicate
the way. Perhaps the lines really are getting processed in their
entirety now and some othe
> Thanks for your work, doesn't show any improvements for me however (but
> adds about 25% to compile time).
25% is a huge overhead, that's not just the time taken to duplicate
the way. Perhaps the lines really are getting processed in their
entirety now and some other reason is causing them no
Mark Burton wrote:
OK, let's try again. The attached patch adds a duplicate() method to
the Way class.
It's only really needed when using the continue patch. You will have to
edit StyledConverter.class in the do while loop where it's
looping around until foundType.isFinal() and in the body of
OK, let's try again. The attached patch adds a duplicate() method to
the Way class.
It's only really needed when using the continue patch. You will have to
edit StyledConverter.class in the do while loop where it's
looping around until foundType.isFinal() and in the body of the loop
it is calling
Felix,
forget that last patch - it doesn't do the copy early enough - I shall
rework it.
Mark
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Felix,
> highway=* & oneway=yes {set name "{name} oneway"} [0x27 resolution 24
> continue]
> highway=residential [0x07 resolution 22]
>
> Usually now every street with oneway=yes I have an additional line
> displaying small arrows to indicate street is oneay.
> However using link-pois-to-ways
Mark Burton wrote:
Hi Felix,
here is the last version (working up to 1277 flawless)
Well, I can't see where the problem is at the moment. I did find and
fix a trivial bug while looking at the code introduced by 1278 so the
time was not wasted!
When you say "created with continue comm
Hi Felix,
> here is the last version (working up to 1277 flawless)
Well, I can't see where the problem is at the moment. I did find and
fix a trivial bug while looking at the code introduced by 1278 so the
time was not wasted!
When you say "created with continue command", what does that mean? C
Mark Burton wrote:
Hi Felix,
Could someone please recheck the "continue" patch for the
--link-pois-to-ways action?
If using --link-pois-to-ways all lines created with "continue" command
that are affected by a POI are not shown/created.
I am not familiar with the continue patch but if
Hi Felix,
> Could someone please recheck the "continue" patch for the
> --link-pois-to-ways action?
> If using --link-pois-to-ways all lines created with "continue" command
> that are affected by a POI are not shown/created.
I am not familiar with the continue patch but if you post it (or emai
Could someone please recheck the "continue" patch for the
--link-pois-to-ways action?
If using --link-pois-to-ways all lines created with "continue" command
that are affected by a POI are not shown/created.
svn commit wrote:
> Version 1278 was commited by markb on 2009-10-15 09:49:26 +0100 (Thu,
Mark Burton escribió:
> Carlos,
>
>
>>> Arguably, yes. However, I ran out of energy before I could implement
>>> that. The bollard code does very similar things but, to be honest, I
>>> can't really be bothered at this time. If someone else wants to
>>> implement that, I will happily integrate t
Carlos,
> > Arguably, yes. However, I ran out of energy before I could implement
> > that. The bollard code does very similar things but, to be honest, I
> > can't really be bothered at this time. If someone else wants to
> > implement that, I will happily integrate their patch. My feeling was
>
Mark Burton escribió:
> Hi Carlos,
>
>
>> What happens if the distance between the tagged POI and the
>> next/previous points is very long? Shouldn't it be a limit to the length
>> affected by the reduction/increase of road_speed/road_class?
>>
>
> Arguably, yes. However, I ran out of energ
Hi Carlos,
> What happens if the distance between the tagged POI and the
> next/previous points is very long? Shouldn't it be a limit to the length
> affected by the reduction/increase of road_speed/road_class?
Arguably, yes. However, I ran out of energy before I could implement
that. The bollar
svn commit escribió:
> Version 1278 was commited by markb on 2009-10-15 09:49:26 +0100 (Thu, 15 Oct
> 2009)
>
> Add ability to set a road's class and speed from a CoordPOI.
>
> If the way has a point with a POI that has mkgmap:road-class or
> mkgmap:road-speed tags they will be transferred to the
Version 1278 was commited by markb on 2009-10-15 09:49:26 +0100 (Thu, 15 Oct
2009)
Add ability to set a road's class and speed from a CoordPOI.
If the way has a point with a POI that has mkgmap:road-class or
mkgmap:road-speed tags they will be transferred to the way along with any
mkgmap:road-
25 matches
Mail list logo
