Version 1488 was commited by marko on 2010-01-18 08:13:28 + (Mon, 18 Jan
2010)
RuleFileReader.optimiseAndSaveBinaryOp(): Try to be symmetric.
optimiseAndSaveAndOr(): Refactored from optimiseAndSaveBinaryOp().
___
mkgmap-dev mailing list
On 18/01/10 07:47, Marko Mäkelä wrote:
Hi Marko
I see. I guess that only the first matching [] rule will be run
and that any {set} or {add} rules will not affect further tests.
There is a 'continue' keyword that allows further matches to take
place.
The set and add actions are expected to
Hi Steve,
I see. I guess that only the first matching [] rule will be run
and that any {set} or {add} rules will not affect further tests.
There is a 'continue' keyword that allows further matches to take
place.
The 'continue' keyword is for the [] action, right? And the further
Version 1489 was commited by marko on 2010-01-18 09:23:08 + (Mon, 18 Jan
2010)
In the default style, correctly set mkgmap:unpaved
based on smoothness and sac_scale.
In the regexps, the meta-characters |()*? are not to be escaped.
___
mkgmap-dev
On 16.01.2010 12:03, Mark Burton wrote:
Thinking some more about what I was seeing in mapsource when mousing
around the Baltic map, I came to the conclusion that the edges of the
overview map bounding boxes where in the wrong place so I took a look
at mkgmap where it rounds those coords
Version 1490 was commited by marko on 2010-01-18 10:10:53 + (Mon, 18 Jan
2010)
Give a more appropriate example
in the comment of RuleFileReader.optimiseAndSaveAndOr().
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
On Mon, Jan 18, 2010 at 09:10:49AM +, Steve Ratcliffe wrote:
On 18/01/10 08:13, svn commit wrote:
RuleFileReader.optimiseAndSaveBinaryOp(): Try to be symmetric.
optimiseAndSaveAndOr(): Refactored from optimiseAndSaveBinaryOp().
So you are trying to transform
a=b (c=d|e=f)
to
On 18.01.2010 10:35, Mark Burton wrote:
Felix,
Nope, still broken. This patch even made it worse on my test. Some POI
got dropped that were displayed before.
The overview map (as can be seen here) is shifted about 1.5km to the east.
Your picture only shows 1 tile. You have to
I think I reported something similar a while back, and it was fixed by
reverting some revision. This one is somewhat different, because the
crash occurs with Geofabrik's finland.osm.bz2 from Jan 18 (today), but
Jan 13 is fine.
I am using mkgmap r1490 and splitter r103.
Exception in thread main
[duplicate message, original got lost?]
Hi Felix,
Okay, on maps in the northern hemisphere without patch no problem. In
maps of the southern hemisphere with and without patch I loose the
tooltip for a small stretch.
OK, thanks.
That's quite different from what I get here on my GB map
Hi Marko
a~b (c=d|e=f)
OK cool, that is an example where it would be useful.
I see, there can be at most one search key per rule? So, it would seem to
make sense to put the most selective condition first. And I guess then
it would not make sense to move the isType(OR) checks before
Hi Steve,
There are lots more things that do not work, here are a few that I've
just tried out:
1. a~b# doesn't work
2. a~b c=d # works
3. a~b c~d e=f# doesn't work.
4. (a~b | c~d) e=f # works
5a (a~b | c~d) e=f g=h # doesn't work
5b ((a~b | c~d) e=f) g=h #
Hi Felix,
On Mon, Jan 18, 2010 at 02:19:45PM +0100, Felix Hartmann wrote:
Actually I found two ways how to make it work. Sometimes the mkgmap
style-file code allows so many nice workarounds. :-)
*a)* the odd way
rcn_ref=* rcn_ref=10{ name '${rcn_ref}' } [0x01701 resolution 22
On 18.01.2010 12:37, Mark Burton wrote:
[duplicate message, original got lost?]
Hi Felix,
Okay, on maps in the northern hemisphere without patch no problem. In
maps of the southern hemisphere with and without patch I loose the
tooltip for a small stretch.
OK, thanks.
That's
On 18.01.2010 14:48, Marko Mäkelä wrote:
Hi Felix,
On Mon, Jan 18, 2010 at 02:19:45PM +0100, Felix Hartmann wrote:
Actually I found two ways how to make it work. Sometimes the mkgmap
style-file code allows so many nice workarounds. :-)
*a)* the odd way
rcn_ref=* rcn_ref=10{
On 18.01.2010 12:06, Mark Burton wrote:
Hi Felix,
Okay, on maps in the northern hemisphere without patch no problem. In
maps of the southern hemisphere with and without patch I loose the
tooltip for a small stretch.
OK, thanks.
That's quite different from what I get here on
On 18.01.2010 15:40, Torsten Leistikow wrote:
Felix Hartmann schrieb am 18.01.2010 15:00:
No, the trick is not working, as the you cannot run continue for
asking the same value twice.
This is not an intended feature, it is simply a bug in the multiple elements
patch, which made
Felix,
Maybe it would be best to find out why the overview map does not fit if
created with mkgmap. If I use maptk it fits 100%.
What resolution is the overview map created by maptk? mkgmap uses 13.
Mark
___
mkgmap-dev mailing list
Felix Hartmann schrieb am 18.01.2010 15:42:
The style branch never worked with continue at all, that was the main
problem. At least for me.
I can not confirm this. I am using the style branch combined with the continue
statement.
The style branch is not 100% error free, but in my opinion its
On 18.01.2010 15:44, Mark Burton wrote:
Felix,
Maybe it would be best to find out why the overview map does not fit if
created with mkgmap. If I use maptk it fits 100%.
What resolution is the overview map created by maptk? mkgmap uses 13.
Mark
For my maps, I have lowest
On 18.01.2010 15:18, Marko Mäkelä wrote:
Hi Felix, Steve,
On Mon, Jan 18, 2010 at 03:00:06PM +0100, Felix Hartmann wrote:
rcn_ref=10 [0x02 resolution 24 continue]
rcn_ref=10 [0x03 resolution 24] --- is identical to the line above and
will not work.
Is there any reason for
Version 1491 was commited by steve on 2010-01-18 17:48:48 + (Mon, 18 Jan
2010)
The NSIS install builder can now include index and TYP files
including pre-built index files.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
Version 1492 was commited by steve on 2010-01-18 17:53:22 + (Mon, 18 Jan
2010)
Read of highways is one or two bytes depending on
how many there are.
Plus some code tidying.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
On 18.01.2010 13:19, Mark Burton wrote:
Felix,
I am guessing that the oversize sea sector is getting dropped somehow
by the clipping. Hopefully, WanMil will issue a new version that only
bloats the sea box when MP is being used.
Yes, I changed his code so that it only bloats
Felix,
Which file is this supposed to be in?
Osm5x...
Well if it works, I think you should submit this patch, the mp patches
and the extend-sea patches into trunk. It all seems to work very well.
Ideally, WanMill will add that change to his MP code and then issue a
new patch that can
However, there is still a problem in that with your v3 patch in place,
I no longer get any sea polygons visible when I use
generate-sea=polygons. I wonder if the change you made to the size of
the sea polygons is responsible for that? Could you please change that
code so that it only produces the
This is just a rework of my earlier patch with the filter class renamed
so that there can be no doubt as to what it does.
As before, the rational behind this is to stop the DP filter from
deleting the end points of lines that have been introduced by either
the clipper or the polygon splitter
Version 1493 was commited by steve on 2010-01-18 18:24:58 + (Mon, 18 Jan
2010)
BRANCH: mp
Only produce oversize sea polygons when
generateSeaUsingMP is true.
- WanMil
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
On 18.01.2010 19:36, Steve Ratcliffe wrote:
On 18/01/10 18:05, WanMil wrote:
Attached patch (against the mp branch) solves this.
OK thanks, applied.
Is everyone happy that this is now a big improvement over trunk?
..Steve
Please put the extend-sea patch also into the
Hi Steve,
On 18/01/10 18:05, WanMil wrote:
Attached patch (against the mp branch) solves this.
OK thanks, applied.
Is everyone happy that this is now a big improvement over trunk?
It's performed well when processing the Baltic map.
One thought, and I may be completely wrong here
Felix,
Please put the extend-sea patch also into the branch...
I am hoping that Ronny will provide a new version that includes the
missing help blurb.
Mark
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
On 18.01.2010 19:53, Mark Burton wrote:
Felix,
Please put the extend-sea patch also into the branch...
I am hoping that Ronny will provide a new version that includes the
missing help blurb.
he did already. 4th message in the thread about the patch where he added
some
Am 18.01.2010 01:05, schrieb Mark Burton:
Ronny,
Sorry, I missed this before. Could you please add a line to the
generate-sea help blurb that describes the new option and also
add similar words in the appropriate place in resources/help/en/options.
Thanks,
Mark
Hi,
Added the help texts in
Hi Steve,
On 18/01/10 18:05, WanMil wrote:
Attached patch (against the mp branch) solves this.
OK thanks, applied.
Is everyone happy that this is now a big improvement over trunk?
It's performed well when processing the Baltic map.
One thought, and I may be completely wrong here
On 01/15/2010 02:37 PM, Chris Miller wrote:
unpacker we're using isn't all that great... If you're sure the planet file
is OK and suspect the bz2 code is at fault, you could uncompress the planet
file (assuming you have a spare 140GB or so!) and try again.
You were right, the bz2 code was
Hi Steve,
On Mon, Jan 18, 2010 at 05:09:05PM +, Steve Ratcliffe wrote:
I produced the attached patch which makes all the previous examples
compile (apart from the plain a~b example).
Great! The algorithm looks OK to me.
I have some remarks about it, using stricter type casts, adding
Version 1495 was commited by steve on 2010-01-18 21:41:34 + (Mon, 18 Jan
2010)
BRANCH: mp
a few updates towards the project style
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Version 1497 was commited by steve on 2010-01-18 22:36:58 + (Mon, 18 Jan
2010)
Merge the mp branch to trunk.
Patches were written by WanMil.
See ^/branches/m...@1496
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
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 not just the first two terms. So if there
Hi
I have a map of the UK with sea (using --generate-sea=extend-sea-sectors)
This is much better than the last time I tried as it was faster and
there is no flooded land.
I do get a lot of horizontal and vertical artefacts when zoomed out
that go away when I zoom in.
I assumed that Mark's
Hi Steve,
Hi
I have a map of the UK with sea (using --generate-sea=extend-sea-sectors)
This is much better than the last time I tried as it was faster and
there is no flooded land.
I do get a lot of horizontal and vertical artefacts when zoomed out
that go away when I zoom in.
I
On 19.01.2010 00:50, Mark Burton wrote:
Also, if you compare our sea with, say, the NZ open GPS map (built
using cgpsmapper), there's a lot more artifacts in the NZ map than
there is now in our maps (either using polygons or multipolygon).
And in response to what Felix has just posted, the
Hi Mark
My patch doesn't fix the H V artifacts - I believe those are caused
by mapsource (they also appear in maps made with cgpsmapper).
Oh OK, I've attached a picture of the worst bit - that is expected then?
I took another look at the NZ maps on your suggestion and there are
indeed a
Hi Felix
I have never seen it so bad. The lines should ONLY appear on tile
boundaries. Now please don't tell me those are all tile boundaries ???
No they are not tile boundaries, they are boundaries between sea polygons.
It is the worst area, most of the map is much better than that.
..Steve
On 19.01.2010 00:59, Steve Ratcliffe wrote:
Hi
Mark
My patch doesn't fix the H V artifacts
- I believe those are caused
by mapsource (they also appear in maps made with cgpsmapper).
Oh OK, I've attached a picture of the worst bit - that is expected
then?
I took
On 19.01.2010 01:05, Steve Ratcliffe wrote:
Hi Felix
I have never seen it so bad. The lines should ONLY appear on tile
boundaries. Now please don't tell me those are all tile boundaries ???
No they are not tile boundaries, they are boundaries between sea polygons.
Steve,
Oh OK, I've attached a picture of the worst bit - that is expected then?
Hmm, that's particularly bad, attached is what I get when using
multipolygon (and my h v patch). As you can see, not bad at all.
Zooming in and out doesn't make it change very much.
I took another look at the NZ
Actually, I'm really impressed that the mp code can handle that tile at
all in a reasonable time.
It's interesting to look at it in mapedit. You can see exactly how the
sea has been split to fit around the islands.
FYI mapedit reports over 16000 sea polys for that tile. By comparison,
if I use
Hi Mark
Hmm, that's particularly bad, attached is what I get when using
multipolygon (and my h v patch). As you can see, not bad at all.
Zooming in and out doesn't make it change very much.
All (or almost all at least) of the lines I see go away
when I zoom in. In gpsmapedit, I don't notice
Hi Felix
Some comments on the items in your list that I am planning to look at
or have comments on:
1. Address Search only working in Mapsource (or inside active tile on
old generation GPS)
Is a Legend Cx old generation? On mine I can find addresses in
different tiles, but not always, some
Version 1499 was commited by marko on 2010-01-19 06:55:59 + (Tue, 19 Jan
2010)
Add static qualifiers and use stricter Op types in RuleFileReader.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
I am getting these for yesterday's finland.osm.bz2 and mkgmap r1499.
I suspect that these are coming from the branches/mp merge:
SEVERE (MultiPolygonRelation): Multipolygon
http://www.openstreetmap.org/browse/relation/5828 contains intersected ways
This relation or the containing points have
52 matches
Mail list logo
