The flodded areas was a reason of the attitude of the mp code: mp does
not recognize that polygon pi is in polygon po if they share a line or a
point.
The attached patch contains an easy workaround. The sea background area
(which is the outer area in the mp) is increased by 1 so that it does
Hi WanMil,
I get these errors when compiling with that patch:
[javac]
/home/markb/OSM/mkgmap-git-svn/src/uk/me/parabola/mkgmap/reader/osm/MultiPolygonRelation.java:1065:
cannot find symbol
[javac] symbol : method isLoggable(java.util.logging.Level)
[javac] location: class
Hi Felix,
Thank you for testing my patch. In any case, I will try to figure out
what caused the size difference for me. Even if the patch does not seem
to bring much CPU-wise, the compact notation could be useful in some cases.
But as your example shows, the downside of the compactness would be
Hi Greg,
Last night, I wrote:
We could do that, but I just got another idea: I will create a simple
TYP file with http://ati.land.cz/gps/typdecomp/ and try to decompile
it by hand into source file(s) that would be compiled with GNU Assembler
to the TYP file. That should be enough for my
Have you tried using the source code? I tried, but failed. It does not
even claim to be the entire program. The web interface is deliberately
No, I have not tried. That doesn't sound encouraging.
pgp0tnJPvGn0a.pgp
Description: PGP signature
On Jan 17, 2010, at 11:40, Marko Mäkelä wrote:
Have you tried using the source code?
I did take a look at this some time ago. I noted that there were a lot of
dependencies (such as imagemagick) which could cause troubles. Instead I used
the source code to help me understand the TYP file
On 17.01.2010 11:20, Marko Mäkelä wrote:
Hi Felix,
Thank you for testing my patch. In any case, I will try to figure out
what caused the size difference for me. Even if the patch does not seem
to bring much CPU-wise, the compact notation could be useful in some cases.
But as your example
On Sun, Jan 17, 2010 at 04:11:51PM +0100, Felix Hartmann wrote:
Something fundamentally fucks up in with your patch or there is again
some typo that I made?
Something fundamental seems to be wrong. I did not look how the matching
is actually done.
Marko
Hello.
It's some months I noticed a problem. Very often building Italy and using lates
splitter (97..103) and lates mkgmap (varies) the map has some routing problem.
In fact trying complex routes (example: from a side of Rome to the other),
mapsource is sometimes unable to find the route and
Hello Johann,
I have not tested this patch. I expect it to work, but I think it is a
suboptimal solution.
I make no claims that it is optimal. Merely, that it's cheap and
cheerful. It achieves the desired aim with very little computational
overhead.
You set the preserve bit on all lines
Hi WanMil,
W The attached way 39612875 is still missing two nodes 474857138 and
W 474857142.
I've just taken a look at this. Those two nodes don't appear in the austria.osm
file at all, so it's not too surprising they're not in the splitter output
either :)
Regards,
Chris
Version 1485 was commited by marko on 2010-01-17 20:03:29 + (Sun, 17 Jan
2010)
Polish RuleFileReader.optimiseAndSaveBinaryOp() a little.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
Hi
There is code for generating TYP files under the ...imgfmt.app.typ
package, and I may have some more code from Thomas that what is checked
in which I could send you if you want to follow that route.
..Steve
___
mkgmap-dev mailing list
Hi Steve,
It doesn't work like that, so we don't do multiple hash lookups and
equality comparisons for each rule.
We go through the tags and look each one up, based
on an index consisting of the tag and value. So all rules that could
be matched by say natural=mud are indexed by the string
Hi Mark,
MB That appears to work right. Please add the option (and also consider
MB adding an overall bounds option as well!)
I've just checked in some changes that adds a --no-trim parameter to the
splitter to disable the trimming of empty areas around the edges of tiles.
Chris
Hi WanMil,
W The attached way 39612875 is still missing two nodes 474857138 and
W 474857142.
I've just taken a look at this. Those two nodes don't appear in the
austria.osm
file at all, so it's not too surprising they're not in the splitter output
either :)
Regards,
Chris
Oh, so
Hi Steve,
There is code for generating TYP files under the ...imgfmt.app.typ
package, and I may have some more code from Thomas that what is checked
in which I could send you if you want to follow that route.
Thanks, it could be a good long-term solution.
In any case, I will first have to
Hi Chris,
I've just checked in some changes that adds a --no-trim parameter to the
splitter to disable the trimming of empty areas around the edges of tiles.
I will give it a go.
Thanks,
Mark
___
mkgmap-dev mailing list
Hi WanMil,
The v3 patch is working well with the Baltic map. The main land masses
are there and I haven't yet spotted any missing islands.
One issue, the boundaries of the tiles are visible on the land at all
zoom levels (see visible-tile-boundaries.png). The boundaries are not
visible on the
Hi WanMil,
The v3 patch is working well with the Baltic map. The main land masses
are there and I haven't yet spotted any missing islands.
One issue, the boundaries of the tiles are visible on the land at all
zoom levels (see visible-tile-boundaries.png). The boundaries are not
visible on
WanMil,
My workaround was based on the assumption that all polygons created by
the mp code will be clipped to the bounding box later (by the style
code). Can you confirm that?
Yes, polys are clipped in StyledConverter.addShape().
I looked at the output using mapedit and the land has no
WanMil,
Good news - I don't think it's your problem. I disabled the sea
generation completely and the lines on the tile edges are still there.
Haven't a clue what's causing them (and I don't care because they don't
show up when I use generate-sea=polygons).
One issue that I don't think you can
WanMil,
Good news - I don't think it's your problem. I disabled the sea
generation completely and the lines on the tile edges are still there.
Haven't a clue what's causing them (and I don't care because they don't
show up when I use generate-sea=polygons).
One issue that I don't think
Another idea is to introduce a kind of ShapeDetector which tries to
regenerate the original shape of a tile / OSM dump. I don't have a good
idea how to do this and I have less idea how to do this in acceptable time.
Maybe we can use an java.awt.geom.Area object and add all lines with a
WanMil,
Good news - I don't think it's your problem. I disabled the sea
generation completely and the lines on the tile edges are still there.
Oops, I may have spoken too soon. With your v3 patch in place, I made a
new map with generate-sea=polygons and not only are the lines still
there, all
Version 1486 was commited by steve on 2010-01-17 23:08:26 + (Sun, 17 Jan
2010)
BRANCH: mp
Lots of fixes of multipolygon issues.
I have also added some more javadoc and code comments, renamed methods
and variables and removed not very useful logging statements.
- WanMil
Hi Ronny,
this patch (against 1485) adds a new option for generate-sea:
extend-sea-sectors
If this option is set, coastlines not reaching the borders of a map will
be extended with a point at the nearest border.
This prevents strange things happening at the borders of geofabrik extracts.
Version 1487 was commited by steve on 2010-01-17 23:33:42 + (Sun, 17 Jan
2010)
BRANCH: mp
The sea background
area (which is the outer area in the mp) is increased by 1 so that it
does not share any lines and points with any of the inner areas.
Fixes flodded areas problem arising from the
On 18.01.2010 00:13, Mark Burton wrote:
Hi Ronny,
this patch (against 1485) adds a new option for generate-sea:
extend-sea-sectors
If this option is set, coastlines not reaching the borders of a map will
be extended with a point at the nearest border.
This prevents strange things
Am 18.01.2010 00:13, schrieb Mark Burton:
Hi Ronny,
this patch (against 1485) adds a new option for generate-sea:
extend-sea-sectors
If this option is set, coastlines not reaching the borders of a map will
be extended with a point at the nearest border.
This prevents strange things happening
Hi Felix,
I just tried out this patch on Italy from geofabrik (on trunk plus
wanmil's mp patch v3) and it was the first time for me that I got a
correct sea generation (using
--generate-sea=polygons,no-sea-sectors,extend-sea-sectors),
(well the sea was empty so I had to color 0x4b
Hi Ronny,
OK. I added some comments. Hope this explains what is done.
Thanks for that quick response.
Felix has already tested your patch and is getting good results so it
looks good for committing.
Mark
___
mkgmap-dev mailing list
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
___
mkgmap-dev mailing list
On 17/01/10 20:06, Marko Mäkelä wrote:
Hi Marko
1. What if there are multiple actions for natural=mud?
Which one(s) will be processed and in which order?
If there are multiple rules with the first term natural=mud then they
are put into a list in the order that they occur in the file. They
On 18.01.2010 00:53, Mark Burton wrote:
Hi Felix,
I just tried out this patch on Italy from geofabrik (on trunk plus
wanmil's mp patch v3) and it was the first time for me that I got a
correct sea generation (using
--generate-sea=polygons,no-sea-sectors,extend-sea-sectors),
(well the
dropping --no-sea-sectors did not help. Still sea got omitted if not
using polygons.
Probably someone should analyse what's the problem in Italy, maybe then
the bug why polygons is not working as expected can be found.
The good thing is in principal it should work...
Felix,
Ups, just noticed that that once I zoom in to closer than 3km in Italy
everything is flooded (in Denmark there is no problem) as 0x10100 is not
set on resolution 24-20 (only 17-19) ( when using
--generate-sea=polygons,no-sea-sectors,extend-sea-sectors option and
then setting
Hi,
Using polish-format as input, polylines exceeding MAX_POINTS_IN_LINE in
LineSplitterFilter.java, will be splitted in a part which gets the
original routeparam values and a splitted part where the routeparam
seems to be unset.(e.g Line Typ 0x07 speedclass=2(40km/h) roadclass=0
will be
Hi Steve,
If there are multiple rules with the first term natural=mud then they
are put into a list in the order that they occur in the file. They are
then evaluated in order until one matches. Only the conditions after
natural=mud are run, eg for the rules:
natural=mud colour=brown
39 matches
Mail list logo
