On 19.01.2010 00:02, svn commit wrote:
Version 1498 was commited by steve on 2010-01-18 23:02:57 + (Mon, 18 Jan
2010)
Reduces style rule syntax errors that are caused
by terms being in the wrong order.
Terms in the expression are now re-arranged accross the whole of the
expression and no
Hi WanMil,
On Fri, Jan 22, 2010 at 12:19:31AM +0100, WanMil wrote:
> Attached patch can be summarized very easy:
>
> * Major speedup for mp code
>
> Please test and commit if no problems arise.
Sorry for nitpicking, but could you please fix a few formatting issues
and comments in the patch? Some
Hi Carlos,
> OK, I see. It's due to bridges I have introduced recently in my maps. In
> some of my attempts to get bridges working I had to add road_class and
> road_speed to the bridges lines. I suppose removing them will solve the
> problem, won't it?
Yes, adding class or speed makes a way int
Mark Burton escribió:
> Hello Carlos,
>
>
>> Since yesterday the number of similar arcs warnings has increased very
>> much, but when you look at the supposed wrong data, they are correct and
>> there are no recent changes. May be recent commits have introduced some
>> bug in this regard. You ca
Attached patch can be summarized very easy:
* Major speedup for mp code
Please test and commit if no problems arise.
WanMil
Index: src/uk/me/parabola/mkgmap/reader/osm/MultiPolygonRelation.java
===
--- src/uk/me/parabola/mkgmap/rea
On 21.01.2010 21:54, Torsten Leistikow wrote:
> Felix Hartmann schrieb am 21.01.2010 19:07:
>
>> I wouldn't see (except the strange handling of oneway=reverse - but
>> maybe there is some error on my side) any strange behaviour with the
>> trunk currently.
>>
> We had quite some topics
Felix Hartmann schrieb am 21.01.2010 19:07:
> I wouldn't see (except the strange handling of oneway=reverse - but
> maybe there is some error on my side) any strange behaviour with the
> trunk currently.
We had quite some topics lately, e.g. that you can not use the same expression
twice, or tha
Hello Carlos,
> Since yesterday the number of similar arcs warnings has increased very
> much, but when you look at the supposed wrong data, they are correct and
> there are no recent changes. May be recent commits have introduced some
> bug in this regard. You can have a look at this one for exa
> Carlos Dávila escribió:
>> Since yesterday
> Sorry, it was day before yesterday when it started to happen, so mp
> merge may be related.
>> the number of similar arcs warnings has increased very
>> much, but when you look at the supposed wrong data, they are correct and
>> there are no recent
Steve Ratcliffe schrieb am 21.01.2010 18:26:
> OK I shall start on it very soon.
That's great news for me, Steve. Thanks!
Gruss
Torsten
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Carlos Dávila escribió:
> Since yesterday
Sorry, it was day before yesterday when it started to happen, so mp
merge may be related.
> the number of similar arcs warnings has increased very
> much, but when you look at the supposed wrong data, they are correct and
> there are no recent changes. May
Since yesterday the number of similar arcs warnings has increased very
much, but when you look at the supposed wrong data, they are correct and
there are no recent changes. May be recent commits have introduced some
bug in this regard. You can have a look at this one for example:
2010/01/21 09:14:3
On 21.01.2010 18:55, Steve Ratcliffe wrote:
> On 21/01/10 17:28, Felix Hartmann wrote:
>
>> Not that no 0x* is included here. This would be simple and effective
>> (and I can't think of any reason why we would need the style branch then).
>>
> We need the style branch because the trunk
On 21/01/10 17:28, Felix Hartmann wrote:
> Not that no 0x* is included here. This would be simple and effective
> (and I can't think of any reason why we would need the style branch then).
We need the style branch because the trunk just doesn't work in a
consistent and predictable way. I know th
On 21.01.2010 18:26, Steve Ratcliffe wrote:
> Hi
>
>
>> And once again I plead for a resurrection of the style branch, so that we can
>> clean-up the style handling of mkgmap.
>>
> OK I shall start on it very soon. I'm sure it will conflict a lot with
> the 'continue' patch that was ad
Hi
> And once again I plead for a resurrection of the style branch, so that we can
> clean-up the style handling of mkgmap.
OK I shall start on it very soon. I'm sure it will conflict a lot with
the 'continue' patch that was added to the trunk, so that will have to
be sorted out.
..Steve
Felix Hartmann schrieb am 21.01.2010 13:51:
> This has come since the latest additions to the style-file rules.
And once again I plead for a resurrection of the style branch, so that we can
clean-up the style handling of mkgmap.
Gruss
Torsten
___
mkgmap
Felix Hartmann schrieb am 21.01.2010 02:31:
> I already had quite a few ideas/concepts copied by Garmin map
> compilers (e.g. using assymetric transparent lines - which was so
> forgotten by Garmin or not intended that they stopped supporting it
> until copying many parts for the Garmin Transa
I noticed that during the last updates oneway=reverse is behaving very
very strange.
If I have the following rules:
highway=* & oneway=reverse & incline=up & mtb:scale:uphill>4 {set
oneway=-1} [0x01]
highway=* & incline=up & mtb:scale:uphill>4 {set oneway=yes} [0x02]
Strangely way is output as
Felix Hartmann escribió:
> On 21.01.2010 11:00, Carlos Dávila wrote:
>
>> Felix Hartmann escribió:
>>
>>
>>> You are using types that Mapsource does not display. As simple. 0x2b is
>>> the last line type Mapsource is using. GPS works to 0x3f.
>>> You have to use extended (5 digit) types
>Splitter.jar is not eating my relations, but there could be bugs in it.
>Can you please post your areas.list file and the IDs of some eaten relations.
>Do the member ways or nodes cross tile boundaries?
Hi Marko, here you can find the content of my areas.list file:
# List of areas
# Generated Th
On 21.01.2010 11:00, Carlos Dávila wrote:
> Felix Hartmann escribió:
>
>> You are using types that Mapsource does not display. As simple. 0x2b is
>> the last line type Mapsource is using. GPS works to 0x3f.
>> You have to use extended (5 digit) types instead.
>>
> Great! At last I can h
Felix Hartmann escribió:
> You are using types that Mapsource does not display. As simple. 0x2b is
> the last line type Mapsource is using. GPS works to 0x3f.
> You have to use extended (5 digit) types instead.
Great! At last I can have bridges on my maps. I've used 0x10600-2 and
they show both on
On 21.01.2010 08:30, Marko Mäkelä wrote:
> Hi Felix,
>
> On Thu, Jan 21, 2010 at 02:31:19AM +0100, Felix Hartmann wrote:
>
>> My main concern is that Garmin map publishers (like Onroute) use large
>> parts of my style-file to have better autorouting and produce closed
>> source commercial map
24 matches
Mail list logo
